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1.0 INTRODUCTION 


This Manual is designed to serve as a suppleMent to the 
ATARI^O0 CTMT and ATARI800CTMT OPERATING SYSTEM MANUAL. 

The A1200, as shown in sections 3-5, is a technical 
upgrade of the A800. The operating system for the 
A1200 has been written to Maintain, as much as 
possible, compatibility with application programs which 
have already been developed for the A^0O/8O0? 

Since the basic hardware which controls the user 
interface and the display is, for the most part, 
compatible with the earlier designs, the operating 
system, except for the enhancements or changes 
described here, has remained largely the same. 
Therefore the data contained in the OS manual for the 
A^O 0/80 0 is still valid. 

This manual has been written to provide the user with 
data regarding usage of the added features of the A1200 
operating system, with some details about the 
characteristics of the peripheral devices with which it 
will operate. Programmers or peripheral developers who 
require a greater level of detail regarding the 
handling of peripheral devices should refer to the 
documents referenced in item 2 of section 2 below. 



2,0 APPLICABLE DOCUMENTS 


1, ATARI Heme Computer Operating Systems Manual. 

Describes the OS Tor the A^OO and A80 0 . 
which is the basis for the enhancements 
described in this manual. 

2. SERIAL INPUT/OUTPUT INTERFACE USER'S HANDBOOK 
PART 1. 

yjiis document provides a detailed explanation 
of the interface requirements and the timing 
relationships for the serial communications 
capabilities of all of the units 
(A^OO/800/1200). 


3. ATARI Home Computer Hardware Manual and A1200 

Supplement♦ 

The Hardware Manual covers the hardware 
registers which control the various functions 
of the A^OO and A800. The supplement to the 
hardware manual covers the added features for 
control of the A1200. Such details which are 
appropriate to the OS handling of such 

hardware registers ARE contained in this OS 
manual. The user who has need for other 
hardware-related data should refer to the 
hardware manual for more information. 

DE RE ATARI 

This document provides the user with an 
introduction to the effective use of the 
ATARI Home Computer hardware. Although 

written to cover the A^00/800t the data 
contained therein is valid for the A1200 as 
wel 1. 



3*0 HOW THE A12 0 0 COMPARES TO THE A^00/800 



The following is 3 list of the features and functions 
which will be discussed in this chapter* Each will be 
explained in a separate section* 

In this chaptert you will learn about* 

1* The HELP Key 

2* The Function Keys 

3* How key codes are redefined arid which ones 
cannot be redefined 

How to alter the key repeat rate 

5* The action of the Caps/Lowr Key 

6* How the OS initializes the LED' s on the keyboard 

7* What happens when a cartridge is installed or 
removed 

8* What happens during power-on self-test* 

9* What the option juMper assignements Mean 

10* What new screen nodes the A1200 can use 

11* How to enable fine scrolling of the text screen 

12* How the disk handler has been changed for inproved 
operation 

13* What kind of display is now produced at power-up 

What features have been deleted as compared to the 
A^OO or A80 0 


Each of the items enumerated above corresponds to the 
paragraph number in this section which follows* For 
example, item 1 above is covered in paragraph 3*1, item 
2 in paragraph 3*2 and so forth* 


c# 



3*1 The HELP Key 



9 


(• 


The operating systeM, while watching the Keyboard* will recognize 
the pressing of the HELP key as a request to set a flag in the OS 
database* This flag can be read by whichever application prograM 
is in control at the tine and react accordingly* 


No ATASCII keycode is created for passing to the applications 
program. Only the database variable is affected. Therefore if 
your prograM is expecting the Help key to be pressed* you Must 
not only watch the keyboard for inconing ATASCII codes other than 
Help, but also occasionally check ("poll") the contents of the 
HELF'FG (help flag) database variable to see if Help was 
r equested♦ 


The location of this variable is $02DC* The conditions to which 
it responds are listed below, along with the codes which will be 
stored in HELF’FG* 


Hex value Condition represented 

00 The Help flag is cleared* This flag is cleared 

at initial power-up reset and subsequently, if 
set* Must be cleared by the application prograM. 


11 HELP key alone was pressed* 

51 SHIFT-HELP key coMbination was pressed. 

91 CTRL-HELF’ key coMbination was pressed. 

The HELF’ key can be used during the power-on display and during 
the self test feature. See those sections for More inforMation. 


3.2 What The FUNCTION Keys Do 

The A1200 is provided with a set of four function keys* You May 
redefine the ATASCII values which these keys produce if you 
desire* As a Matter of fact, the entire keyboard ATASCII output 
nay redefined as will be seen later» This section shows the 

nor M 3 1 definition of the F1-F4 keys, their functions and the 
ATASCII codes which they produce (if any) as a result of the 
power—on reset assignMent. All values in the table below are 
given in hexadecinal. 

FUNCTION KEY ASSIGNMENT SUMMARY 

Key If pressed alone 

FI Produces the Cursor—up function, returns ATASCII 1C 

P2 Produces the Cursor—down function, returns ATASCII ID 

F3 Produces the Cursor—left function, returns ATASCII IE 

F-q Produces the Cursor-right function, returns ATASCII IF 
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FUNCTION KEY ASSIGNMENT SUMMARY (eont'd) 

Key If pressed with SHIFT 

FI See HOME CURSOR below 

F2 See CURSOR TO LOWER LEFT CORNER below 

F3 See CURSOR TO BEGINNING OF PHYSICAL LINE below 

F4 See CURSOR TO FAR RIGHT OF PHYSICAL LINE below 

Key If pressed with CTRL 

FI See KEYBOARD ENABLE/DISABLE below 

F2 See SCREEN DMA ENABLE/DISABLE below 

F3 See KEY-CLICK ENABLE/DISABLE below 

See DOMESTIC/INTERNATIONAL CHARACTER SET below 

Key If pressed with CTRL+SHIFT 

FI Ignored 

F2 Ignored 

F3 Ignored 

F3 Ignored 


HOME CURSOR FUNCTION 

SHIFT-F1 causes the cursor to Move to the ho«e position of the 
screen as well as producing the default ATASCII code 1C. The 
default code is reassignable. however the hone cursor function 
will renain assigned to this key coobination regardless of the 
code to be produced. 


CURSOR TO LOWER LEFT CORNER 

SHIFT-F2 causes the cursor to nove to the lower left corner of 
the screen as well as producing the default ATASCII code ID. The 
default code is reassignable. however this cursor Move function 
will renain assigned to this key coMbination regardless of the 
code to be produced. 


CURSOR TO BEGINNING OF PHYSICAL LINE 

SHIFT-F3 causes the cursor to Move to the far left of the 
physical line on which it is located (note* not the logical line 
which. in the screen editor. could be as Many as 3 physical 
lines.) This function is perforned by the screen editor as well 
3 5 generating the default ATASCII code IE. The default code is 
reassignable. however this cursor Move function will renain 
assigned to this key conbination regardless of the code to be 
P roduced♦ 
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CURSOR TO FAR RIGHT WITHIN PHYSICAL LINE 


SHIFT-F^ causes the cursor to Move to the far right side of the 
physical line on which it is located* This function is perforned 
by the screen editor as well as generating the default ATASCII 
code IF. The default code is reassignable, however this cursor 
nove function will renoin assigned to this key coMbination 
regardless of the code to be produced. 

KEYBOARD ENABLE/DISABLE 

CTRL-F1 controls the keyboard enable/disable function. It 
produces no ATASCII code. This key eonbinotion affects the 
operating systen handling of the keyboard and is not 
reassignable. 


SCREEN DMA ENABLE/DISABLE 


CTRL-F2 controls the Screen Enable/Disable Direct Menory Access 
(DMA). It produces no ATASCII code. This key coMbination 
affects the operating systen handling of the display function. 
This key coMbination is not reassignable♦ 

The A1200, on power-up, always enables the screen DMA. What this 
Means is that the systeM will always initialize itself to display 
anything which has been defined for the screen display during power 
up. This saMe screen DMA enable will also occur if you touch any 
keyboard key other than the CTRL—F2 coMbination. 


Various types of prograMS which you write May be heavily involved 
in arithmetic conputations. To speed up the processing, in the 
A^OO or A800, you May disable the screen DMA. When it is 
disabled, the ANTIC processor does not steal MeMory cycles froM 
the 6502 to get its data for the screen. Therefore during 
disable Mode, the screen reMains blank. When it is enabled, the 
full display which you have defined is visible, however, the 
processor is slowed down by anywhere froM 10 to ^0 percent as 
explained in the section on ANTIC DMA in the Atari Hardware 
Manual. 

On the A1200, to start the higher speed/ no display function, 
press the CTRL-F2 key coMbination. The display will go blank. 
To restore the display again at any tine, you can press any other 
key ♦ 


During your arithmetic calculations, you May be in continuous 
process of updating the MeMory area where the display data is 
contained. You can then get a status of the operation in process 
at any tifie siMply by pressing any key other than CTRL-F2, then 
again press CTRL-F2 to re-enter the higher speed Mode. 
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Your program , "then# on completion of the calculation) could 
exercise direct program control over the ANTIC DMA variable to 
restore the display when the arithmetic intensive part is over. 
(See the ATARI Home Computer Hardware Manual for data on 
programmed control of this variable.) 


KEY-CLICK ENABLE/DISABLE 

CTRL-F3 controls the Key-Click enable/disable function. If 
pressed once, it disables the audible feedback on keystrokes. 
Pressed again reenables it. This function combination only 
affects an OS database variable and produces no ATASCII code. It 
is not reassignable. 

You may control the key click enable/disable from your program. 
All that needs to be done is to change the same flag which the 
operating system uses to indicate whether a key click is 
required. This flag is called NOCLIK. It is one of the OS 
database variables, contained at location $02DB. 

On power up and reset, the operating system initializes this 
variable to a value of 00, meaning that key click is enabled. 
This location, when it contains the value $FF, indicates that no 
key click is desired. The key combination CTRL-F3 toggles it 
between the values 00 and FF. 

In addition to this flag, when the operating system controls the 
keyboard, it tells you the enable/disable status using the light 
emitting diode number 1 (referred to as LED 1.) Whenever the 
operating system disables the keyboard, it will light LED 1 i 
whenever it enables the keyboard, it will turn it off. The 
operating system does not change the status of the light if YOU 
disable or re-enable the keyboard under program control. 



DOMESTIC/INTERNATIONAL CHARACTER SELECTION 


CTRL-F4 controls the domestic/international character selection. 
Default is domestic. It affects an OS database variable only and 
produces no ATASCII code. It is not reassignable. It toggles 
the display of character sets, changing between the two each tine 
the key combination is pressed. When the international character 
set is selected. LED number 2 will be lit. 

The international version of the character set is located in the 
ROM beginning at location $CC00. You can cause the international 
character set to be selected by storing the constant $CC to 
location ^OZF'l. This is the location CHBAS♦ The normal character 
set is located in the ROM starting at $E000. If a program stores 
$E0 to CHBAS. it selects the display of the normal characters. 

If you have defined your own character set. however. pressing 
CTRL-F-9 will display the international character set. This is 
because the operating system will test CHBAS and find that the 
value $C8 is not there. Therefore $C8 must be the next value 
which is to be used (selects int'l set). When it tests CHBAS and 
finds $C8 stored there. it knows that $E0 is the next value to 
use during the toggle between character sets. 


3.3 KEY REDEFINITION 

You may redefine most of the A12O0 console keys if desired. The 
redefinition process consists of setting up a pair of tables 
which can be referenced by the operating system when it 
translates your keystroke into an ATASCII value. 

The two tables are the KEY Definition Table and the Function Key 
Definition Table. The operating system has a pair of data tables 
from which the normal definitions are made. You may define your 
own set of tables however. then simply tell the operating system 
where they are located in memory. 

One such use of key redefinition might be to experiment with 
other. possibly more efficient keyboard layouts, such as perhaps 
the Dvorak keyboard. An example is given in Appendix A of a 
keyboard redefinition to allow you to do such an experiment. 
(Over the years, the QWERTY key layout has been the accepted 
standard however many people have found DVORAK to be more 
efficient. This would allow you to try it for yourself.) 



CONTENTS OF THE KEY DEFINITION TABLE 


This table allows Most of the keys of the A1200 to generate any 
desired ATASCII code or special internal function. The 
exceptions to this are listed at the end of this section. To 
redefine the keys. it is necessary first to define an area in 
MeMory where a 192 byte table May be stored. Into this table, 
you will store the definitiions of the keys which you desire. 
Later you will tell the operating systeM where this table is 
located so that future references May be Made to it instead of 
the standard definition table. 

The organization of this table is as follows? 


+- 

i 

Lower case convert. 

-+ 

1 

< Starts 

at 

user defined 

address) 

1 

Group of 6^ bytes 

1 

_ 4. 

The 

table 

of 

lower case 

conversions 

4* — 

l 

i 

Shift plus key 

Group of 64 bytes 

1 

1 

The 

table 

of 

upper case 

conversions 

+— 

l 

l 

CTRL plus key 

Group of 64 bytes 

-+ 

1 

1 

The 

table 

of 

control key 

COMbO 

+- 


-+ 

conversions 




The bottoM-Most byte in the table shown above is at the address 
KEYT ABLE_START + 191. 

The reason that each of the subdivisions of the table has 64 
bytes in it is that the hardware can generate a total of 6^ 
hardware keycodes. These codes. nuMbered 00 — 63 deciMal (00 — 3F 
hexadeciMal) are used to index directly into one of the three 
keycode tables. Which table is referenced depends on whether the 
CTRL or SHIFT keys are pressed. 

Note that there is no table for the coMbination of both CTRL and 
SHIFT. This coMbination is invalid and is ignored by the 
operating systeM. 

Each of the three 64 byte subsections of the table has the forn? 


+-+ 

| 00 code I Byte 0 contains conversion for key code 00 

| for key alone, key with CTRL, or 

+_+ key plus SHIFT. Depends on which 

| 01 code I table is accessed per which keys pressed. 

I I 

+-+ Byte 1 contains conversion for key code 01 

I I 


I I 

+-+ 

| 3F code I Byte 3F contains conversion for key code 3F 

I I 

+-+ 
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The codes which you piece in your 'table will either generate en 
ATASCII code (for direct character translation) or they will tell 
the system to perform a specific function. Specifically any code 
in the range of 80 to 92 hexadecimal will be treated as special 
by the system. This is illustrated in the table below. 


CODES AND THEIR EFFECT ON THE SYSTEM AFTER TRANSLATION 
CODE EFFECT (if any) 

00 thru 7F Used as the ATASCII code only. 

92 thru FF Used as the ATASCII code only. 


80 


Ignore, invalid key combination. 


81 


Invert the video output to the screen. 


82 


Alpha lock/Lower case toggle. 


83 


Alpha lock 


84 


Control Lock 


85 


End of file 


86 


ATASCII code 


87 


ATASCII code 


88 


"Gonio" function 


89 


Key click on/off 


8A 


Function 1 * 


8B 


Function 2 * 


8C 


Function 3 * 


8D 


Function 4 * 


* 

note: 

When it sees these keycode translations. it is told 

to 

DO 

the 

function which is described in the Function 

Key 

desc 

r ip t i 

ons. This function will be a cursor move and 

is 


independent of the ATASCII code which the specific Function Key 
will produce. The ATASCII coded generation for the normal and 
shifted function keys is handled in a different table. whose 
description follows that for the keycode hardware translate 
table. 


8E 

Cursor 

8F 

Cursor 

90 

Cursor 

91 

Cursor 


to home 
to bottom 

to the left margin 
to the right margin 


The table below shows the key cap corresponding to each key code. 
The physical position of each key switch within the table 
determines the hardware code which it will generate. To 
determine what code it is. take the row address of the cap. and 
add it to the column address. The result is the hexadecimal value 
returned to the operating system (range 00—3F) for use in the 
table lookup for that key. 
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KEYCODE DEFINITIONS TABLE 


0 12 3 4 5 6 7 

+-h-h-4--+-1--H-*- 

00 | L I J I t |F1 |F2 I K I + I * I 

+-h -h-+-+-+-+-+-+ 

OB | 0 | | P I U I RET | I I - I = I 

+-+-+-4*-4--4--h-4--4- 

10 I V I HLP I C I F3 I F4 I E: I X | Z I 

+-+-+-+-+-+-+ --+-+ 

18 | 4 I | 3 I 6 | ESC I 5 | 2 I 1 I 

+-h-h-h-4-f---*■-^ 

201,1 SPACE| ♦ I N I |M|/|)I<I 

+-+-+-+-+-+-+-+-+ 

28 I R I I E I Y I TAB I T I W I Q I 

-(-H-1-1-1- 1 -*-4- 4- 

30 | 9 I |0|7 |BACKS| 8 | < I > I 

+-H-+-+-+-+-+-+-+ 

38 I F I H I D | I CAPS| G I S I A I 

+ - + - + - +-+-+-+-+-+ 

As an example the key cap "C” is in the table in row 10, column 
2. This means that the hardware generates a hardware code 10+2 
or 12 hexadecimal. Therefore, in the translation tables shown 
above, the function code or ATASCII code for this character will 
stored in the key definition table position $12 for each of 
the three types of "C" which are valid ( c alone, Shifted C, or 
Control C), You may cause each of these perform a separate 
function or generate a separate ATASCII code by revising the 
tables, 

you have decided on how you want your keys to be redefined, 
you tell the operating system where it may find the definitions 
by storing the address of those definitions in locations 79 and 
7A hexadecimal. 

The low byte of the hexadecimal address where you have stored the 
y 5 should be placed in location 79, the high byte is location 
7A, This is defined as one of the system vectors. It will point 
to the default, or original key definition table at power-on 
reset time. 












REASSIGNMENT OF THE FUNCTION KEYS ONLY 


There nay be tines when you only want to redefine the function 
keys and not redefine the rest of the keyboard. The A1200 
operating system allows you to redefine these keys only by 
setting up an 8-byte table in place of the 192 byte table which 
would have otherwise been required. The format of this table is 
as follows! 


+-+ 

| FI I <- Lowest memory location of the table 

+-+ 

I F2 I 

+-+ 

I F3 I 

+-+ 

I F4 I 

+-+ 

| SHIFT-F1 I 

+-+ 

| SHIFT-F2 I 

+-+ 

| SHIFT-F3 | 

+-h 

| SHIFT-F'*} I <-Highest memory location of the table 

+-+ 


When you have decided what functions each combination must 
perform and have built the table. change the system vector FKDEF 
to point to the lowest address of your table. This vector is 
located at memory locations 60 and 61 hexadecimal. Location 60 
gets the low byte of the hex address, location 61 gets the high 
byte . 


NDN-REASSIGNABLE KEYS AND KEY COMBINATIONS 

The following keys or key combinations are either specifically 
wired for special functions or are subjected to special handling 
by the operating system. 

Even though there might be a hardware-generated key code shown in 
the table above, and a corresponding space in the translate 
tables, there is no way to reassign these functions. This is 
because the operating system traps the hardware code directly to 
perform the specified function and it never gets to the translate 
mode. These keys or combinations are as follows! 

BREAK — This function is fixed as a special case in 

the operating system. It is sensed by the hardware. 

SHIFT — This key is an integral part of the hardware 

encoding of any key function. 


q 












CTRL — This key is an integral part of the hardware 

encoding of any key function. 


OPTION - 
SELECT 
START - 

RESET — 
HELP — 

CTRL-1 

CTRL-F1 


CTRL-F2 

CTRL-F3 

CTRL-F^ 


+ 

|- All of these are directly wired to and are 

+ sensed by the GTIA circuitry. 


Directly wired to the 6502 reset line. 

Function is fixed by the operating systen. 

The help function handling is described 
elsewhere in this Manual. 

Screen output start/stop function. Trapped 
by the operating systen at the hardware key 
decode level# controls the listing start/stop 
function. See the Users Manual for the A1200. 


This key conbination is used as the keyboard 
enable/disable function. If it is pressed while 
the keyboard is enabled# it will disable all 
keyboard functions with exception of the 
f ollowing l 

CTRL-F1 can still be used to re-enable# 

RESET is the 6502 reset key# 
cannot be disabled# 

OPTION/START/SELECT not controlled by the 
operating systen. 

See SCREEN DMA CONTROL above. As noted there# this 

function is not reassignable. 

See KEY-CLICK ENABLE/DISABLE above. As noted there# 
this function is not reassignable. 

See DOMESTIC/INTERNATIONAL CHARACTER SET above. 
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3 ♦ T USER-ALTERABLE KEY AUTO-REPEAT RATE 


The A1200 operating systen allows you to control the rate at 
which a key> continuously held down# will repeat its entry to the 
systen* This change nay be done under progran control by 
nodifying the OS database variable called KEYREP. It is located 
at hex address 02DA* 

This variable deternines the repetition rate by counting the 
nunber of VBLANK (vertical blanking) intervals which occur* For 
the NTSC (60 Hz) systen# the initial value of this variable is 6J 
for PAL systens# the value is 5* This assures a uniforn repeat 
rate of 10 characters per second for either systen. 

Under control of this variable# the naxinun "controllable" key 
repeat rate would be 50 characters per second on the PAL# and 60 
characters per second on the NTSC (screen refresh rate)* This 
would occur with a value of 1 in this variable. 

You nay also control the initial delay which occurs before the 
key repeat starts. The OS database variable which controls this 
is called KRPDEL * Its hex address is 02D9. 

It controls the nunber of VBLANKs which nust occur between the 
sensing of the key pressed until the first repeat occurs. Fron 
that tine on# the repeat rate is controlled as described above. 
The initial values used by the OS provide a 0.8 second initial 
delay for either NTSC (count = ^8) or PAL (count = -90) systens. 


3.5 CAPS/LOWR KEY TOGGLE ACTION 

The CAPS/LOWR key on the A1200 functions as shown in the chart 
below♦ 


KEY COMBINATION 

CAPS 

CAPS 

CAPS 

SHIFT-CAPS 

CTRL-CAPS 

CTRL-SHIFT-CAPS 


CURRENT STATE 

Control Lock 
Alpha Lock 
Lower Case 

- any - 

- any - 

- any - 


NEW STATE 

Lower Case 
Lower Case 
Alpha Lock 
Alpha Lock 
Control Lock 

- no change 


The Meaning of the terns 


is as f ollows * 


Lower Case - All key caps respond in lower case node 
Alpha Lock - All alphabetic keys (A-Z) respond in 

upper case node# all other keys lower case 
— All keys respond as though the control 
l< e y i s being held down as well as the 
selected key 


I l 


Control Lock 



3.6 LED INITIALIZATION 


The A1200 has two LED's on the front panel, called LED 1. and LED 
2. LED 1, when lit, indicates that the Keyboard is disabled. LED 
2, when lit, indicates that the international character set is 
selected. The operating system enables the keyboard and selects 
the domestic character set on power up and reset. Therefore 
these LED's will both be off. 


3.7 GAME CARTRIDGE REMOVE/INSERT INTERLOCK 

In the ATO 0 and A800 , the cartridge interlock mechanism 
physically renoved the power fron the entire systen when the 
cartridge door was opened. 

The A1200 no longer requires this power down of the entire 
systen. It does, however, autonatically cause a power-up 
initialization sequence to occur if a cartridge change is 
detected while the power is on. 

The initialization sequence itself contains a junp through the 
cartridge initialization address which adjusts the A1200 to this 
cartridge immediately upon its insertion. Likewise, if a 
cartridge is removed, the system reconfigures itself through the 
power on sequence, to be a no-cartridge system. This 
initialization is handled by the Stage 2 VBLANK routine. 


3.B POWER-ON SELF-TEST 

During the initial power-on, the A1200 operating system will 
perform the following quick check of the integrity of the system 
RAM and ROM: 

a. Is it possible to write $FF (all ones) to all RAM locations? 

b. Is it possible to write $00 (all zeros) to all RAM locations? 

c. Does a checksum of the two ROM's compare to that stored 
within each ROM? 

If any of these tests fail, the operating system will transfer 
control to the self-test memory test routine. Here a more 
thorough test of both RAM and ROM can take place. 



3.9 


OPTION JUMPERS 


The A1200 is provided with a set of four hardware junpers which 
are designed to tell the operating systen how the systen is 
configured. As of the date of this writing, only one of the four 
jumpers has been assigned, specifically J1♦ This is specified in 
the table below. During the power-on sequence, the A1200 
operating systen reads the state of these junpers and stores this 
state in the OS database variable JMPERS, location 030E. 

The bit assignnents for each of the four junpers is as specified 
below. The bits are all active low, Meaning that if a line 

reads a digital zero, the junper is installed. 

BIT FUNCTION HARDWARE NAME 

0 Self test enable (will run self test if low) J1 (pot 4) 

1—3 Reserved for future use 
4-7 Unused 


3.10 ADDITIONAL HARDWARE SCREEN MODES 

The A1200 adds direct access to the renaining special purpose 
display processor operating nodes. The table below shows the 
current napping which had been provided for the A400 and A800. 
The table which follows thereafter shows the added nodes and the 
nunbers which the software can use to access the extra nodes. 

Mode napping connon to A400/A800. 


ANTIC MODE GTIA MODE 


2 

($02) 

0 

6 

($06) 

0 

7 

($07) 

0 

8 

($08) 

0 

9 

($09) 

0 

10 

( $ 0 A > 

0 

11 

( $ 0 B) 

0 

13 

($0D ) 

0 

15 

($ OF ) 

0 

15 

($0F) 

1 

15 

($ OF ) 

2 

15 

( $0F) 

3 


Software Mode 

0 ($ 00 ) 

1 ($ 01 ) 

2 ($ 02 ) 

3 ($03) 

4 ($04) 

5 ($05) 

6 ($06) 

7 ($07) 

8 ($ 08 ) 

9 ($09) 

10 ( $ 0 A ) 

11 ($ 0 B) 

Mode napping for 


Sof twsre 

Mode 

12 

($0C) 

13 

(SOD) 

14 

($ 0E ) 

15 

( $ OF) 


A1200 (additional)J 

ANTIC MODE 

4 ($04) 

5 ($05) 

12 ($0C) 

14 ($ 0E) 


GTIA MODE 

0 (note 1 ) 

0 (note 1 ) 

0 
0 
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Note i: The existing character sets will not provide 

recognizable characters for these new nodes* Therefore 
you will have to provide the character set if you use 
these nodes* This is done by defining the full 

character set, then nodifying the OS database variable 
CHBAS to point to the nost significant byte of the 
address at which the character set starts* 

Appendix E: of this nanual contains sone suggestions on 
the nethod for designing a new character set to support 
these added nodes* 

3.11 TEXT SCREEN FINE SCROLLING 

The screen editor (Et) now supports fine scrolling of the text 
screen data as an option. This fine scrolling option will be 
enabled if the database variable FINE (hex location 026E) is set 
nonzero prior to issuing the OF’EN connand to the screen editor* 
Likewise the feature will be disabled if this location is set to 
0 0 before issuing the OF'EN. 


3.12 DISK COMMUNICATIONS ENHANCEMENTS 

The A1200 adds the capability for the resident disk handler to 
read and write disk sectors having variable length fron 1 to 
65536 bytes. The default length, as is used on the A^fOO and A800 
currently, is 128 bytes. Both at power-on and RESET (warn 
start), the 128 byte sector length is established. Your program 
can alter -this length by Modifying the OS database variable 
DSCTLN. The location of this two-byte variable is 02D5 and 02D6 
(lo byte in 02D5, hi in 02D6). 

In addition to the capability to read and write variable length 
sectors, the A1200 also adds the capability to write a sector to 
the disk without a read-verify operation always following it. 
This is the connand 'F' which was specifically excluded in the 
previous releases of the operating system. 

With this capability added, you have a choice of either using the 
verify, for systen integrity (always read after write). Or you 
can take a chance of writing a bad sector on rare occasions but 
increasing your average speed of disk usage by sone value related 
to the verify tine. You nay want to experinent with sone of your 
prograns with and without verify to see the results. 


3.13 POWER-ON DISPLAY ENHANCEMENT 

In place of the original power—on neno pad display used by the 
A^OO and A800 (in the absence of a cartridge or disk), the A1200 
displays a dynanic ATARI rainbow. If you press the HELP key while 
the rainbow is displayed, the A1200 will enter the self-test node. 
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1.0 MEMORY MAF' OF THE A120 0 


The following table shows how the 6502 processor 
perceives the various address spaces which it can 
access. The MaxiMun allowable address range, with the 
16 bit address of the 6502 is hexadeciMal 0000—FFFF♦ 
This address range is split. by the hardware nenory 
nanageMent circuitry, as follows! 

(Note! The A1200 uses 64K RAM's as the nain systen 
writeable Menory. Addresses within those RAM's, which 
would normally have filled the entire nenory access 
space of 0000-FFFF of the processor, are prevented fron 
access by the nenory Manager . This allows ROM's, 
cartridge nenory, and peripherals to occupy a part of 
the neMory space as is noted below.) 


A1200 MEMORY MAP 

HEX ADDRESS WHAT IS ACCESSED THERE NOTES 

FFFF-D800 OS-ROM or RAM if ROM disabled 1 

D7FF-D0 0 0 Active low chip selects are 

produced for the peripheral 


chips through 
nenory page. 

accesses in this 

Menory Mapped 

I/O Space split 

as DO 0 0-D0FF 

GTIA 

D20 0-D2FF 

POKEY 

D300-D3FF 

PIA 

D'lO 0-D*tFF 

ANTIC 

D500-D5FF 

Any access read 


or write to an 
address in this 
range enables the 
cartridge control 
line CCNTL on the 
cartridge inter¬ 
face (sane as A"100/ 

A80 0)♦ 

D100-D1FF. D600-D6FF. and 
D700-D7FF are reserved for 
future use. 

OS-ROM physically present, but 2 

cannot be accessed here. 


CFFF-C0 0 0 OS-ROM or RAM if ROM is disabled 1 





HEX ADDRESS 
BFFF-AOOO 


9FFF-8000 


WHAT IS ACCESSED THERE NOTES 

RAM, or cartridge interface 

if RD5 line is pulled up to 
+5D by the cartridge board. 

A120 0 MEMORY MAR (cor.t'd) 

RAM, or cartridge interface 

if RD^ line is pulled up to 
+ 5D by the cartridge board. 


i 7FFF-580 0 
57FF-50 0 0 
^FFF-0000 


RAM 

RAM, unless in self-test node 
RAM 


NOTES: 1. Access to the OS ROM nay be disabled by 

writing a zero to port Ei of the PIA, bit F'EiO. 
Access is nornally enabled, with a 1 present 
in this bit. (When changing this bit in the 
register, other bits should not be changed.) 


2. The self-test ROM code is physically 
present in the OS ROM at actual address D000— 
D7FF. However, this area is used for the 
access to the nenory napped I/O devices. 
When the self-test feature is invoked, the 
RAM located fron 5000-57FF is disabled. The 
nenory Manager renaps the nenory access such 
that the OS ROM physical addresses D000-D7FF 
are accessed at 5000-57FF. The nenory Manager 
uses port E: of the PIA, bit PE:7 to deter nine 
whether to access RAM or ROM in the region 
5000-57FF. PE:7, if high, accesses RAM. If 
low, causes an OS-ROM access instead. (When 
changing this bit in the register, other bits 
should not be changed.) 


(Port 8 was used in the A400/800 to service 
the gane ports 3 and ^♦ The use of the 
renaining bits of this port are specified 
elsewhere in this Manual.) 


\ 



5*0 ENHANCEMENTS TO THE A^00/800 REV. E: OPERATING 
SYSTEM INCORPORATED IN THE A1200 


This section describes 3 set of enhancements which 
include new methods of handling peripheral products 
and, in a separate section, improvements in basic 
operations of the system. The latter might be referred 
to as "bug fixes". 


PERIPHERAL HANDLER ADDITIONS 

To accommodate a new class of peripheral devices, the 
operating system now includes a relocating loader, used 
to upload peripheral handlers through the serial I/O 
interf ace♦ 

In the A^00/800, device handlers for the peripherals 
were uploaded as fixed location (absolute) object code. 
These handlers were loaded using a set of device 
inquiries, or polls, known as types 0, 1 and 2. These 
polls are described further in the Atari -900 and 800 OS 
Manual. 

The A1200 adds two other types of polls to its 
operating system. One poll, known as type 3, is issued 
at power-on or reset time. The other, type *1, can be 
issued as a result of an OPEN command by an application 
program. 


Type 3 Poll Command 

The type 3 poll command itself is used as an "Are You 
There?* 1 type of command. Associated with the type 3 
poll are two other types, specifically the? 

a) Poll Reset 

and b> Null Poll 


Poll Reset consists of the following SIO 
sequence (refer to the SIO document 
explanation of the byte types)? 


command byte 
for further 


Byte Position Value (hex) 


Device Address ^F 
Command Byte ^0 
AUX1 "»F 
AUX2 ^F 


Command Checksum Normal 


(checked by peripheral) 




1 



The 4F in AUX1 and AUX2 define this sequence to all 
peripherals as a poll reset* 

After responding to a type 3 poll by sending a handler 
to the system, a peripheral is not supposed to respond 
again to a type 3 poll* The Poll Reset conwand, at 
power-up» resets all type 3 peripherals, freeing then 
to respond to the poll request* However, no serial bus 
device sends back any data as a result of a poll reset 
confiand * 


Type 3 Poll (Are you there?) 

There nay be several types of peripherals which can 
respond to a type 3 poll* In types 0, 1 and 2, the 
device address sent on the serial line specifies which 
exact device is being called♦ In the type 3 poll 
processing, however, the address regains fixed (4F) and 
the devices each respond after a specific nuMber of 
poll 3 retries. In other words, during poll 3 
operations, the coMputer doesn't know which peripherals 
are actually attached, but will keep asking "is anybody 
there" until it has reached its last retry and no 
peripheral has responded* 

Each peripheral which does respond to the type 3 poll 
Must be designed to count the nuMber of retries of type 
3 polls, then to respond as described below on its own 
specified retry slot. Each tine it sees a cownand 
other than a type 3 poll, these peripherals Must reset 
their retry counters* This allows the coMputer to load 
the handler for each peripheral which responds, then 
restart its poll 3 sequence (original retry nuMber 
restored) to look for another poll 3 response fron the 
next peripheral (if any). 

Since each peripheral responds only once (after a poll 
reset), a second request at a specific retry slot 
causes no peripheral response and allows the next 
retry slot to be polled* 

This poll ("are you there?") is sent as follows* 


Byte Position 


Value (hex) 


Device address 
CoMMand Byte 
AUX1 
AUX2 

CoMMand checksum 


4F 

40 

00 

00 

Normal, checked by peripheral 


2 



it is 3 
back the 
interf acet 


When, after checking the retry count, 
peripheral's turn to respond, it sends 
following data to the conputer on the serial 



a) 


An ACK response byte. 


and 


b) 1, Low byte of handler size in bytes (Must be 

EVEN) 


2, High byte of handler size 

3, Device Serial I/O Address to be used 
for loading 

Peripheral Revision NuMber 


These four bytes, if sent by the peripheral, will be 
stored in OS variables DVSTAT (02EA hex) through 
DVSTAT+3, If there is a successful return to the OS 
(not a tiMeout or other problen), it indicates that 
there is a handler to be loaded. The loading is 
perforMed, then the type 3 poll is repeated until all 
retries are exhausted and no peripheral responds. 

Once the device address data is received fron the 
peripheral during this type 3 poll, it can thereafter 
be referenced directly on the serial bus by its address 
in place of the original poll address ■'IF, 


Specific 
receiving 
Appendix C 


details of the actions taken by the OS after 
an answer fron a peripheral May be found in 


Null Poll CoMMand 

This coMMand is used as a serial bus no-operation. If 
any error should occur during loading of a peripheral 
handler or by the relocator, (see appendix C and D>, 
the systeM should be free to "back out" of the linking 
of the faulty loader and tell the peripherals that it 
is ready for the next one to be loaded. Since this 
null poll is a non-type-3 poll, all peripherals will 
have reset their retry counters and should be ready for 
another sequence of retries, looking for their own 
response retry slot. This Maintains synchronization 
between the coMputer and the peripherals. 




3 



The 


structure of the Null Poll 


Byte Position Value 

Device Address ^F 

CoMMand Byte ^0 

AUX1 ^E 

AUX2 ^E 

CottMsnd ChecksuM Normal 


is as follows* 
< hex) 


(peripherals check 


it) 


Type ^ Polling 

This type of poll is sent out on the serial bus as a 
result of an application initiated request* During an 
OPEN co«M 3 nd, a device which responds to a type ^ poll 
nay conditionally or unconditionally be polled to 
deternine if it is online and May or May not have its 
handler uploaded and linked to the systen under control 
of the OS. Detailed inforMation regarding the handling 
of the device under various operating conditions May be 
found in Appendix C. 

The Type ^ Poll is a serial port coMMand 
structured as follows* 

o Device address of ^IF hex (peripherals 
looking for Type ^ Poll May ignore the 
device address and look only for the poll 
coMMand '(?' however» the device 

address will always be ^F hex and the 
peripheral May check this)? 

o CoMMand is '<?' (^0 hex) (peripherals 

looking for this poll will always look tor 
the '(?' coMMand) } 

o Auxl contains the device nane, which is an 
ATASCII upper-case letter (range ^1 hex 
through 5A hex) (the peripheral Must be 
assigned that device na«e in order to 
legally answer the poll)? 

o Aux2 contains the device nunber* which is 
an ATASCII digit (range ATASCII 1 through 
9. 31 hex through 39 hex) (the peripheral 

May optionally use this inforMation in 
deciding whether or not to answer the 
poll)? 

o Standard coMMand cheeksun (peripheral 
checks this). 





This poll differs from the Type 3 Poll in that the 
device nsne and number is included in the poll* 
Therefore the peripheral need not count retries of the 
type 4 poll and should answer the poll as soon as the 
poll command is recognized. There is no limitation on 
the type ^ poll; the peripheral should answer its type 
q poll each time it is issued* 

The peripheral response to a type ^ poll is the same as 
for the type 3 poll. The four response bytes are 
placed* by the computer* into DVSTAT through DVSTAT+3 
(02EA through 02ED hex.). 



GENERAL ENHANCEMENTS TO THE REV* E: OS FUNCTIONS 


The following functions which are supported by the A^00/800 
Rev* B Operating Systen have been further enhanced by the 
addition of the following features! 

Printer CLOSE with data in the buffer - 

The printer handler will insert an EOL (end-of-line) characte 
in the printer buffer t if one is not there, before sending th 
buffer to the printer on a CLOSE* This assures that the las 
line will be printed innediately rather than having the printe 
forced offline to output the final line* 

Printer Unit Nunber Handling - 


The printer handler has been changed so that it will 
process the unit nunber in the IOCE.’, allowing separate 
addressing for printers PI through P8* 

CIO Handling of Truncated Records on Read - 

The CIO now places an EOL in the users input buffer on th 
occurrence of either a record longer than the buffer being rea 
or an EOF being encountered during the read attempt* Thi 
assures that all records are accessible, even if the user ha 
not provided a sufficient buffer size, he will at least get a 
Much of the record as he has provided for* 

CIO Error Handling With Zero Length Buffer - 

The CIO will return a buffer length of zero (in the 6502 A 
register) when there is a handler error while effecting a zeri 
length buffer transfer* (See CIO section in the OS Manual*) 


Display Handler Cursor Handling - 


The display handler now accepts a screen clear code no Mattel 
what value is in the cursor X and Y coordinates* 


Display Handler/Screen Editor heMory Clearing - 


The Display handler and Screen editor will not clear 
beyond the end of MeMory as indicated by RAMTOP* Now 
possible for the user to specify the top of MeMory to 
by the systen and to store device handlers or personal 
code in the MeMory area above the display* Changing 
graphics Modes, then, will not erase any data which 
placed in the RAM area above that assigned for use 
display or screen editor* 


MeMcr' 
it ii 
be usee 
Machine 
display 
has beei 
by th* 




Rework of the Floating Point Package - 

The A1200 operating systen corrects a bug in the Rev E: OS. 
now produces an error status when an attenpt is Made 
calculate the LOG or LOGIO of zero* 

New ROM Vectors - 

The following fixed entry point vectors have been added to th 
A1200 ROM set: 

E^80 JMP PUPDIS entry to power-on display 

E^83 JMP SLFTST entry to the self test pqm 

E^86 JMP PHENTR entry to uploaded handler enter* 

E-489 JMP PHULNK entry to uploaded handler unlink. 

ET8C JMP PHINIS entry to uploaded handler init. 



(# 
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6.0 OTHER CHANGES/GENERAL INFORMATION 


This section deals with items which involve operating systen 
changes, but which do not easily fit into any other category. 


IMPROVED HANDLING OF OS DATABASE VARIABLES 

During normal power-on sequence (cold start), the OS database 
variables from $03ED-$03FF are set to zero. During a RESET (warm 
start), they are NOT changed by the OS. This means that an 
enhanced version of the operating system in the future will be 
able to make use of these locations without reloading them after 
any RESET operation. 

These bytes are all reserved for use in future OS revisions. 


NTSC/PAL VERSION TIMING PROVISIONS 

There are various timing differences between the NTSC (60 hz) and 
the PAL (50 hz> versions. To eliminate the necessity for 
providing a special operating system ROM set for each one, the 
specific timing adjustment values are handled within the single 
ROM set. 


To determine which type of system the ROM is operating on, the 
operating system checks a flag within the GTIA chip and adjusts 
all timings accordingly. This was possible because the GTIA must 
be different to handle the modified display format for the 50 Hz 
version. E:y making certain timings a function of the state of 
this flag, it was possible to make external timings independent 
of the NTSC or PAL system itself. 


The timing values relate to the handling of the 115 Volt 
cassette player (Atari -^lO) and the console auto-repeat rate as 
shown in the table below! 


CASSETTE TIMINGS NOW INDEPENDENT TIMING 


Write Inter-record gap 
Read IRG delay (long) 
Write IRG (short) 

Read IRG delay (short) 
Write File leader 
Read Leader delay 
Beep cue duration 
Beep cue separation 


(long) 3.0 sec. 

2.0 sec. 
0.25 sec. 
0.16 sec. 
19.2 sec. 
9.6 sec. 
0.5 sec« 
0.16 sec. 


Auto-repeat functions now independent Timing 


0.8 sec. 

10.0 char/sec♦ 


Initial delay for auto-repeat 
Repeat rate 



A120 0 OS ROM IDENTIFICATION AND CHECKSUM DATA 


Each of the two ROM's in which the A1200 operating system is 
contained has a capacity of 6^K hits organized as 8K by 8* Within 
each of the ROM's is a block of data organized as shown in the 
diagram below* to identify the ROM and to give its checksum* The 
checksum is tested by the operating system as part of the power 
up sequence* 



The format of the block for the C000-DFFF ROM is as follows 


Checksum which is the arithmetic 
sum of all bytes in ROM except 
the checksum bytes themselves* 


Revision date having the form 
DDMMYY where D=day digit 
M=month digit* Y=year digit 
Each a ^ bit BCD digit* 

Bit 0=0 for C000-DFFF ROM 


Part number having the form 
AANNNNNN* where A's represent 
ASCII characters* N are E-'CD digits* 




+ - 

— 

— 


■4- 



1 

ROM 

Cksufi 

1 <lo) 

1 

cooo 


4-- 



- 

4- 


4-- 

1 

ROM 

Cksum 

1 (hi) 

1 

C001 


+ - 

— 



•4- 


-4 

1 

D1 

1 

D2 

1 

CO 02 

l 

4-- 

— 

-4- 


■4- 


l 

l 

Ml 

1 

M2 

1 

CO 03 

4 - 

+ - 

— 

- 4 --- 


4- 


1 

l 

Y 1 

l 

Y2 

1 

C004 

1 

4-- 

— 

- 4 -- 

— 

4* 


-4- 

l 

Option 

byte 

1 

COOS 


4— 

— 

— 


4 - 


-+ 

l 


A1 


1 

CO 06 

l 

+- 




+ 


l 

l 


A2 


1 

CO 07 

l 

+- 

— 

— 


+ 


1 

1 

N 1 

1 

N 2 

1 

CO 08 

+— 

+- 

— 

- 4 -- 


+ 


l 

l 

N3 

l 

N -1 

1 

CO 09 

l 

+- 

— 

- 4 - - 


4* 


l 

l 

N5 

i 

N6 

1 

CO 0A 

l 

+- 

— 

- + - 


4 - 


-+ 

l 

Revision # 

1 

COOE: 


+- 

— 



4 * 
















The fornst of the identification block for the E000—FFFF ROM is 
as follows* 




+-+ -+ 

I D1 | D2 | FFEE I 

H-— +-+ | 

| Ml | M2 | FFEF +— Revision date having the form 

+-+-+ I DDMMYY where D=day digit 

| Y1 I Y2 | FFFO I M=month digit, Y=year digit 

+-+-+ -+ Each a ■T bit E:CD digit, 

| Option byte | FFF1 EJit 0 = 1 for E000 —FFFF ROM 

+-+ - + 

| A1 I FFF2 I 

+- -+ | 

| A2 I FFF3 I 

+-+ | 

| N1 I N2 | FFF^ +— F’art number having the form 

+-+-+ | AANNNNNN, where A's represent 

| N3 | N^ I FFF5 I ASCII characters, N are BCD digits, 

+-+-+ | 

I N5 I N6 | FFF6 I 

+-+-+ —+ 

| Revision * | FFF7 

+-+ 

| ROM Cksum (lo)| FFF8 

+- -+ +— Checksum which is the arithmetic 

| ROM Cksum < hi>I FFF9 sum of all bytes in ROM except for 

+-+ the checksum bytes themselves, 

| vector table I 

| for NMI, RES | 

| and IRQ I FFFA - FFFF This area reserved for the power on 

+-+ reset vectors, NMI and IRQ vectors. 


OP 
















APPFNDTX A 


AN EXAMPLE OF KEYBOARD REASSIGNMENT 


As suggested earlier in this docunent, the keyboard 
Functions nay be reassigned. The table below gives the 
corresponding keys for the Dvorak (also known as the 
Anerican Sinplified) Keyboard. When the typewriter was 
first invented in 1867. Christopher L. Sholes chose a 
layout for the keys which would slow down the good 
typists of his day and thereby prevent his Machine fron 
jaMMinq. This keyboard has endured to this day. 

In 1932, August Dvorak invented this key layout which 
places the Most often used characters, including the 
vowels, on the "hone" key line and also redistributes 
the keystrokes froM a 60-70% left-hand activity to an 
alnost 50/50 activity. Certain Manufacturers currently 
offer this key layout as an option. Now you can try it 
for yourself if you wish. Only the list of key 
correspondence is given here. It is left to the reader 


■to compose the key 

function 

table 

using the 

* data 

contained 

earlier in 

this Manual 

♦ 



TOP ROW OF 

KEYBOARD 

CENTER 

ROW 

BOTTOM 

ROW 

Current 

Dvorak 

Current Dvorak 

Current 

Dvorak 

0 

? 

A 

A 

Z 

♦ 

♦ 

q 

/ 



z 

♦ 

* 

W 

♦ 

S 

0 

X 

0 

w 

t 





E 

♦ 

D 

E 

c 

J 

e 

♦ 





R 

p 

F 

U 

V 

K 

T 

Y 

G 

I 

B 

X 

Y 

F 

H 

D 

N 

B 

U 

G 

J 

H 

M 

M 

I 

C 

K 

T 

* 

W 





* 

w 

0 

R 

L 

N 

♦ 

V 





♦ 

V 

P 

L 

♦ 

♦ 

S 


Z 



♦ 

t 

s 

/ 

z 

1/4 

• 1 

• • 

_ (underline) 


1/2 

* 

/ 

- 





APPENDIX E: 


SUGGESTIONS FOR THE CONSTRUCTION OF A NEW 
CHARACTER SET FOR THE NEW GRAPHICS MODES 


This appendix covers the new graphics Modes 12* 13* 14 
and 15 now provided on the A12O0. Modes 14 and 15 are 
pure graphics Modes with resolutions of 160 by 20 and 
160 by 40 respectively. Since these are not character 
Modes* the discussion below will be liMited only to 
Modes 12 and 13. 

Graphics 12 and 13 do not produce recognizable 
characters* for the Most part* using the standard 
character set. One will understand why this is true by 
exaMining the following conparison between Graphics 
Mode 0 to 12 and 13. 

Mode 0 is a 40 character Mode. Each character is 
forned out of 8 pixels (sMallest division of the 
screen). Each pixel is 1/2 of a color clock 
wide « 

Modes 12 and 13 are also 40 character Modes. 
However, each character is forMed out of only 4 
pixels, with each pixel 1 color clock wide. This 
forces the character to be the saMe width as that 
used in Graphics Mode 0* but cannot convey the 
sane infornation within 4 bits as with 8 as far as 
character recognition is concerned. (It is 
difficult to forM a recognizable character in a 
four by eight dot Matrix). 

Lets exanine how the 4-pixel character is forMed* again 
coMparing the way the 8-pixel character is forMed in 
Mode 0♦ 

Mode 0 has a choice of two colors for each pixel 
(the hardware Manual says 1 1/2 colors* but it is 
actually either the color and luMinance of 
playfield 2 if there is a zero bit in the selected 
pixel position* or the background color with the 
luninance of playfield 1 if there is a 1 bit in 
the selected pixel position. Therefore each 
single bit in the character definition byte for a 
given line occupies a single 1/2—color—clock—wide 
pixel position. The character set built into the 
OS defines the characters in an 8 by 8 Matrix* 
with one of the 8 bytes which Make up the 
character selected for each of the 8 scan lines 
which comprise the character. 



Mode 12 also uses 8 scan lines per character. 
However, it uses the character bytes in a 
different Manner. Each of the character bytes 
retrieved by the ANTIC is treated as a set of four 
two-bit quantities, where each bit pair describes 
the color which is to be applied to one of the 4 
single color—clock—wide pixels which are part of 
the character. Mode 13 is the sane in its 
treatnent of the data bytes, but each of the 
characters is double—length (16 scan lines instead 
of 8) and each data byte is used twice which 
effectively doubles the length of the character. 


Lets look at a typical character, for exanple a W. The 
bits which for m a W in the character set are sinilar to 
the following} 


1 

0 

0 

0 

0 

0 

0 

1 

displsyt x x 

1 

0 

0 

0 

0 

0 

0 

1 

X X 

1 

0 

0 

1 

1 

0 

0 

1 

X XX X 

1 

0 

0 

1 

1 

0 

0 

1 

X XX X 

1 

0 

1 

0 

0 

1 

0 

1 

XX XX 

1 

1 

0 

0 

0 

0 

1 

1 

XX XX 

1 

1 

0 

0 

0 

0 

1 

1 

XX XX 

1 

0 

0 

0 

0 

0 

0 

1 

X X 


(NOTEJ This is not the exact representation, but is 
used as an exanple of correct interpretation in node 0 
and incorrect interpretation in Modes 12 and 13.) 


If you view the sanple set of bytes, each at 
consecutive addresses within the defined character set, 
it actually looks like a W when you trace the outline 
forned by the l's in the byte set, as shown in the 
display exaMple to the right of the byte 
representation. 


In this Mode 0 display, each of the l's would be one 
color, and each of the zeros would be another color, 
assuring a readable display. 


For the Modes 12 and 13 
controlled as follows* 

If two-bit value is 

00 

01 

10 

11 


the four (not 8) pixels are 


Then the pixel color is} 

the background color 
the playfield 0 color 
the playfield 1 color 

the playfield 2 color 
(if bit 7 of char=0) 


the playfield 3 color 
(if bit 7 of char=l) 
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For the example shown, then, the -9th line fron the 
botton would display a 10 10 01 01 or pixels of 
playfield colors 1, 1, 0, 0 in a row, if the standard 
character set is used. And the botton-nost line would 
display playfield colors 1, BAK, BAK, 0 in a row. As 
nay be inagined, difficult to recognize such a 
character♦ (This character is a nirror inage left to 
right — nonsynnetric characters would be even nore 
difficult to recognize.) 

To build a character set for these nodes 12 and 13, 
then, it is suggested that you build each character as 
double wide, to allow a total of 8 pixels (by 8 lines) 
to define the character. This would also nean 
assigning two character set locations for each 
character and treating each character printed in these 
nodes as two characters to be printed. For the exanple 
of the W, the character set night look like this? 


Byte 

set 

i: 

Byte 

set 

2: 

10 00 

00 

00 

00 

00 

00 

10 

10 00 

00 

00 

00 

00 

00 

10 

10 00 

00 

10 

10 

00 

00 

10 

10 00 

00 

10 

10 

00 

00 

10 

10 00 

10 

00 

00 

10 

00 

10 

10 10 

00 

00 

00 

00 

10 

10 

10 10 

00 

00 

00 

00 

10 

10 

10 00 

00 

00 

00 

00 

00 

10 


Byte set 1 nay represent ATASCII value hex 57 within 
the new character set table, and set 2 nay be at 
ATASCII value hex D7 (hex 57 plus hex 80) if desired. 
You nay feel free, of course, to assign your character 
sets in any Manner you desire. 

Therefore if you would print these two characters side 
by side on the screen, it would becone effectively a 20 
character per line node, with the resultant 10— 
combination treated as the 1-bit in the node 0 exanple 
and the 00-conbination as the 0-bit in the node 0 
exanple, forning a recognizable W in the process. 

Note also that you nay want to design these new 
character sets in a 7 by 7 natrix starting the upper 
left hand corner of the bit-pair set to allow at least 
one blank row and colunn between each of the new 
characters. (This was not done in the exanple). 

Thus nany conbinations of colorful characters nay be 
forned using this technique, allowing the user of the 
A1200 additional flexibility for his prograns. 



APPENDIX C 


SERIAL BUS PERIPHERAL HANDLER LOADING, LINKING, USE 


This appendix contains technical details regarding the serial 
device handlers. It is not written for the general user however 
contains information essential for use by a developer of peripherals 
for the A1200 system. 

A1200 HANDLER LOAD AND RELOCATION DURING POWER-UP PROCESSING 

[Note: The loading procedure described here is also used to load 

handlers when the loading is app1ication—spec ified after power—on has 
completed. The only differences are where in RAM the handler is 
loaded, and handling of loading errors. Accordingly, this single 
section deals with both loading operations. The major point of view 
is toward loading at power—on time to the MEMLO boundary; differences 
for the app1ication—initiated load are noted. See section titled 
APPLICATION—INITIATED LOAD for more on this subject.D 

After a peripheral responds to the Type 3 Poll, the OS will then 
compare the sum of MEMLO (02E7 and 02E8 hex) and the size of the 
handler to be loaded (DVSTAT and DVSTAT+1, 02EA and 02EB hex) to 
MEMTOP (02E5 and 02E6 hex) to determine that there is room to load the 
handler. If there is insufficient room, the handler will not be 
loaded, and the OS issues a Null Poll command (section on A1200 
POLLING DURING POWER-ON) and proceed with further Type 3 Polling 
(POWER-ON COLD STARTstep 9). 

Otherwise the peripheral handler is loaded, starting at MEMLO and 
^proceeding until the load is completed. (Note: the load address may 

also be application specified; see section on APPLICATION-INITIATED 
LOAD. ) The loading operation is achieved using the Operating System's 
relocator (see Appendix D). A call to the relocator is made, 
specifing all parameters needed: 

o Loading address. This is either a copy of MEMLO, or the 

app1ication—supp1ied load address. Before handing this value to 
the relocator, the OS Type 3 Poll process insures that it is 
even—valued by adding one if it is found to be odd; (Note: 
a "Bug" exists in the 6502 processor where a UMP indirect 
instruction will fail if the two-byte indirect pointer is 
relocated across a page boundary. This may be avo ided by 
placing all indirect pointers on even addresses; since 
loading always occurs on even boundaries, the pointer will 
never cross a page boundary. 

o Zero—page loading address. The handler will not load into page 
zero. This address is set to 80 hex; 

o Address of get—byte subroutine described below. 
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TKo buffer is used for storing each block as it is 

The cassette j ** a tQr The final block mag be unfilled; 

oet-bytes .ill stop from the relocator .hen the End record is 
processed* ^so the “e.einin, portion of that block is lynored. 

Serial port load commands are as follotus: 

o Device address taken from Poll response; 

o Load command "St" <26 hex, 038 decimal); 

o Aux1 = block number to be loaded; 

o Aux2 = undefined (must be ignored by peripheral); 
o Appropriate checksum. 

• . — • __i,_e 4 4-o cnnnlu a block whose number is out 

|Whe° r load in^is'be ing "called ^"a^p? icatlonf **;.^;j^”** ^ 

terror 133 (Device Not Open) is returned to the application. 

^is.rir.E'S.r.^ 

^ta^ui All relocates loader errors produce, the results of the 
preceding paragraph. 

responsibi1ity'of^the*pIripheral^desiBn.r to create a proper device 
hand ler. 

The handler must occupy contiguous RAH, ^tarting^^th^load address. 

variablei^o^datal^kcep^that the linkage conventions (section on 
INIT. AND LINKING DURING POWER-ON) must be followed. 

«h.n loaded under application. r.,ue.t. the sire of the area 

for the handler can be l.r.er^h.n the «naction titled 

LOAD?RELOC y . INIT. yisE^. When loaded at HEHLO ^^LINKIN^ 6 

jsiiTF««-a':i;\«;iSr*mJd system reset >«»»>. 
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A1200 INITIALIZATION AND LINKING DURING POWER-UP PROCESSING 


[Note: The handler initia1ization and linking procedures during 

power-up processing are very similar to those during warm—start 
reinitialization and app1ication-initiated handler loading. Therefore# 
this section serves for all processes. It is written in terms of the 
power-up sequence# with occasional test conditions for the warm-start 
variations. The major differences in this procedure between power—up 
and warm-start are described in section titled SYSTEM RESET REINIT. 

App1ication-initiated load is described in section titled 
LOAD, RELOC. , INIT. , USE. 1 

Once loaded, a handler will be linked into the system in three 
way s: 

o The handler's RAM usage will be declared; 

o The handler's name and linkage table address will be entered 
into the handler table; 

o The handler's linkage table will be entered into a linked—list 
of known loaded handlers for System Reset (warm start 
reinitialization). 
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t its load address. This 


The handler will have a linkage table a 
table contains the following: 

OFFSET CONTENTS 

0 _ 14 Standard handler entry vectors (reference A): 

OPEN vector. 

CLOSE vector! 

GETBYTE vector! 

PUTBYTE vector! 

GETSTAT vector! 


SPECIAL vector! 

init ialization code JMPi 


15 


16 - 


18 - 


17 

19 


20 - 21 


Linkage table checksum! 

Handler size in bytes to add to MEMLO. 
Handler linkage table chain forward pointer! 
Zero (reserved for future expansion). 


Byte 15 
sum of b 
it is us 
linkage 
bytes O- 
calculat 
handler 
loaded# 


(checksum) is calculated such that the wrap-around carry 
ytes O through 17 is FF hex (one's-comp1ement negative zero), 
ed bu the operating system to check the integrity of the 
table during system rJset (warm start) reinitialization Since 
17 iU vary^depending on load address the ch,ecksum wi11 be 
ed after the handler is loaded. Bytes 18-19 P°int to the 
linkage table loaded next. If this is the last handler 
this forward pointer is null (zero). 
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The initialization process for a newly loaded handler immediately 
follows its loading: 

CNote: All steps of this process are performed by a subroutine 
which is normally used as part of the OS process of linking new 
handlers into the system. This subroutine can be called by other 
system routines; the calling sequence is discussed in section titled 
SUBROUTINE INTERFACES. As used during power—up loading of handlers 
following Type 3 Polling# the MEMLO parameter used in step 4 is set 
on# indicating that the handler's size is to be added to MEMLO. 3 

1. The OS adds the new handler linkage table at the end of 

the linkage table chain. This is done by starting at the head 
of the chain# CHLINK (in the OS database) and following the 
pointers until a null (zero) pointer is found. For each 
linkage table in the chain (except the last)# the checksum is 
checked to verify the integrity of the linkage table# checksum 
failure results in failure to initialize the newly loaded 
handler# and the rest of this initia1ization procedure is 
bypassed. No error is reported out of the OS during coldstart 
(in this case# polling continues with a Null Poll, followed by 
Type 3 Poll# POWER-ON COLD START step 9). In the case of a 
non-OS caller# the error is indicated to the caller by 
returning with carry bit set. If the checksums are OK, the 
address of the new linkage table# which is the load address of 
the handler# is placed in the null pointer which was at the 
end of the chain. Then the pointer in the new linkage table is 
nulled (zeroed); 

2. The OS loader will then USR to the handler initia 1 ization 
code# 

2a. The handler will initialize itself, optionally utilizing the 
handler table entry subroutine in the resident OS (section 
titled SUBROUTINE INTERFACES). Errors occurring in the 
linking process will produce linking failure (discussed 
below). The handler will initialize itself as follows: 

2b. Call the OS-resident handler table entry subroutine to add a 
handler entry for this new handler; 

2c. Optionally establish the linkage table handler size. The 

handler size could simply have been loaded into the linkage 
table at relocation time# in which case the handler 
initialization procedure now takes no further action. 

A1 ternatively# the handler can calculate the size and insert 
the result during this first initialization. The handler will 
calculate this size only once# and supply the result to the 
operating system in the linkage table at this point during 
power-up initialization. The handler will not modify these 
bytes in the linkage table at any subsequent time. The OS 
flag WARMST can be used to distinguish power—on initialization 
from subsequent warm-start reinit ial i zat ion. The handler size 

need not be returned to the OS if WARMST is nonzero. If the 
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handler calculates its RAM needs, it is responsible for 
insuring that the resulting addition to MEt1 ^ 0 d ° es not 
MEMTOP. Also, it is the handler's responsibility to ensure 
that the size set by the handler is even-valued. It is safe if 
the calculated size does not exceed the size reported by the 
Type 3 Poll (section on PERIPHERAL POLL DURING POWER-ON); 

2d. Return with Carry bit clear if there was no init error) 
otherwise, return with carry set; 

(Note: the handler init need not save any 6502 registers. ) 

3 If the handler initialized unsuccessfully (Carry returned set) 
the new handler linkage table is removed from the 

linkage table chain using the routine described in 
titled SUBROUTINE INTERFACES for that purpose, and the handler 
installation is terminated. In this case, none of the 
following steps is performed; no error indication ^ Jiven out 
of the OS during coldstart, and polling continues with a Poll 
Reset followed by further Type 3 Polling. In the case of a 
non-OS call to this initia1ization process, the error is 
returned to the caller by returning with the carry bit set. 

4 If the handler initialization was successful (Carry returned 
clear) the OS will then check the parameter to see what mode 
of initialization is being performed, to determine whether or 
not the handler size should be added to HEMLO. If the 
parameter is set, then the handler size should be added 
MEMLO. If the parameter is not set. the handler siz 

not be added to MEMLO. In the latter case, the handler size 
entry in the handler linkage table is cleared to zero, 


6 . 


The handler size is added from th< 
MEMLO (02E7 and 02E8 hex); 


handler linkage table to 


The linkage table checksum is 
into the table. This is done 
then calculating the checksum 
table; then storing the one's 
as the calculated checksum of 


calculated and inserted 
by first zeroing the checksum; 
of the first 18 bytes of the 
complement of the resulting sum 
the linkage table. 


n step 2. above, the handler may interrogate th * . 

ARMST to determine the time of initialization. WARMST (0008 hex) 
s zeroed by the OS at the beginning of power-on processing. , 

inless modified by other code in the system. WARMST/^(hix) ShoCld 
he CSYSTEM. RESET! key is pressed, when it is set to FF r should 

his be unacceptable to the handler initialization, the handler snouio 
an variable to keep track of chich initialization to 

iccurring. 

landler table overflow error is a possibility in step 2b. «bove 
-he handler should return with Carry set to indicate initialization 
•ailure, unless it performs some reasonable error recovery. 
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A1200 APPLICATION-INITIATED LOAD 


Most of the loading and initia1ization processes of an 

jpp1icat ion-initiated load are identical to those used for power "J . 
oad Those differences between the two (MEMLO handling) which affect 
t” h.Jl” .r. d!«cu«.e<i in section on INIT. AND LINKING DURING 
POWER-ON. The major difference lies in the polling processes use . 


A1200 APPLICATION-INITIATED OPEN POLL (TYPE 4) 

When an application calls CIO to perform an open, the following 
occurs: 


1 . 


The OS flag HNDLOD (02E9 hex) is interrogated to 
determine whether the application desires a Type 4 Poll for 
the device being opened. HNDLOD=zero means conditional poll 
(step 3); anything else means unconditiona1 poll (step 2); 

CNote: the operating system sets HNDLOD zero at power-on 

and system reset. If the application does not modify HNDLOD, 
conditional poll will always be selected by any OPEN.J 

2. If unconditional poll is selected, a Type 4 Poll (see below) 
occurs. If no peripheral answers, step 7 is performed. If a 
peripheral answers, its 4-byte answer is returned by CIO to 
the application in DVSTAT through DVSTAT+3 (02EA through 02ED 
hex) (proceed to step 6 )j 

3. If conditional poll i. .pocifiod, CIO checks for the device in 
the handler table. If an entry is found, the handler already 
exists and normal open processing continues. Proceed to step 


6. 


If conditional poll is specified and no handler entry is 
found, a Type 4 Poll is issued. Everything proceeds from here 

as in step 2; 

If no poll was issued, this fact is flagged to the calling 
application by setting DVSTAT and DVSTAT+1 (02EA and 02EB hex) 
to zero I/O status returned indicates either successful OPEN, 
or open failure for any of the standard set of possible 
reasons; 

If a poll was issued and successful, the IOCB is nor-M 

"provisionally" opened. This includes all normal CIO OPEN 
processing, but includes none of the handler open 
since the handler is not loaded at this time. The IOCB is 
marked •‘provisionally" open in the following ways: 


The handler table pointer ICHID is set to 7F 


( he x )» 
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o The put address ICPTL#ICPTH is set pointing to the 
OS-resident application loader routine# 

o ICAX3 contains the device name for the handler loader table; 

o ICAX4 contains the device serial address for loading. 

Normal status (01) is returned following a provisional open# 
and DVSTAT through DVSTAT+4 (02EA through 02ED hex) contain 
information needed by the application to provide RAM for the 
handler load which will follow (see below); 

7. If a poll was issued and no device answered# the IOCB is not 
opened and error 130/ Non-existent Device# is returned. 

The OS flag HNDLOD (02E9 hex) is set to zero each time CIO 
returns to the application# regardless of what call was made or the 
results of the call. 



A1200 LOAD. RELOCATION, INITIALIZATION, USE 

Following a "provisional" open the application must check the 
^JVSTAT bytes to determine the need to allocate an area or e 
Ithich is to be loaded. The application must set aside an area, on 
even address, at least as large as the handler size specified 1 
nucTAT . n rf DVSTAT+1 (02EA and 02EB hex). Then the application must 
V addrltlof this area in DVSTAT+2 and DVSTAT-3 (02EC and 02ED 

El^and the length of the area in DVSTAT and DVSTAT+l ( 02EA and 02EB 
hex) (The application may allocate the minimum area by leaving 
DVSTAT and DVSTAT+1 alone.) If the even starting boundary cannot be 
assured by the application, it must allocate one more byte than it 
reports in DVSTAT/DVSTAT+1. The application signals the completion of 
these steps by setting the flag HNDLOD (02E9 hex) nonzero. 

The handler load occurs automatica11y when the application 
calls CIO to perform any I/O operation except CLOSE via the 
"provisionally" open IOCB. when HNDLOD is nonzero (the CLOSE command 
will simply close the IOCB without loading the handler). The steps 
taken by CIO is as follows: 

1. The IOCB is checked to see is it is provisionally open. If it 
is not, normal I/O processing continues; 

2. If the IOCB is provisionally open, the flag HNDLOD is checked. 
If the flag is zero, error 130, Non-existent Device, is 
returned • 

^ 3 If the IOCB is provisionally open and HNDLOD is nonze ™' 

V handler is loaded (using the procedure of section on HANDLER 

LOAD AND RELOCATION DURING POWER-UP) and linked (usins the 
section on INIT. AND LINKING DURINGPOWER-ON>. 
Prior to the load, the load address in DVSTAT+2 & DV J™T+3 
forced even. The initialization process is called wlth 
MEMLO parameter off. indicating that the handler size is not 

added to MEMLO# 

4. If the loading or initialization fails, the IOCB is closed and 
error 130, Non-existent Device, is returned; 

5 If the loading and initialization succeeds, the IOCB is 
modified to indicate it is properly opened: 

o Handler ID, ICHID, is set to point to the proper handler 
table entry. If the entry is not found, error 130. 
Non-existent Device, is returned, and the IOCB is closed. 

o Normal CIO OPEN processing is performed. *"» *!?* 

IOCB properly, including the put address ICPTL, ICPTH wh ich 
is set to point to the handler put-byte entry. Additionally, 
the handler OPEN entry point is called by CIO. 

6. CIO completes processing of the I/O command originally called 
by the application. 



CNote: it is extremely important that the application not modify 
the handler once it has been loaded. Users of high-level languages 
such as BASIC or PASCAL must remain aware of how the language 
environment# particularly the language memory us/age/ may affect the 
handler. DOS 2 users must be aware that the DUP overlays memory which 
could contain I/O handlers. CSYSTEM. RESET3 “uses" loaded handlers via 
the process of reinitia1ization; therefore# system reset processing 
could fail if any loaded handlers have been modified. Also note that 
unpredictable results will occur should the handler be loaded more 
than once by an application. 3 
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A1200 SYSTEM RESET (WARM START) REINITIALIZATION 


This section describes the sequence of events taken by the 
.operating system during system reset (warm start) r e in i t ia 1 i za t i on. 
nhis consists of actions which have existed in the 400/800 revision B 
operating system plus new operations which are the A1200 
enhancements being described in this document. Only that degree of 
detail needed here is included. 

1. The OS sets the warm start flag WARMST (0008 hex) to FF 
he x; 

2. Certain variables in the OS database are cleared to zero. RAM 
outside the OS database is left untouched. In particular, the 
handler table and all IOCB's is zeroed; 



3. MEMLO (02E7 and 02E8 hex) is set to 0700 hex; 

4. OS resident handlers is initialized and entered into the 
handler table; 

5. The application cartridge "A” is initialized, if 
present; 

6. Cassette or disk initia1ization occurs (CASINI or 

DOSINI). At this time, the DOS updates MEMLO by adding its 
size, and any handlers within the DOS are initialized and 
entered into the handler table; 

7. Upon return from the cassette-booted or disk-booted 
reinitialization. the operating system will reinitialize all 
handlers which have been loaded into RAM. The procedure is 
described in detail below; 

8. The OS will start the cartridge or jump through DOSVEC. 


To perform the initia1ization of loaded handlers (step 8 above), 
the operating system will proceed as follows: 

1. The internal pointer CHLINK is checked to see if any handlers 
have been loaded. This pointer is null (zero) if there are no 
loaded handlers, or it points to the linkage table of the 
first such handler; 

2 If a loaded handler exists, its linkage table checksum is 

calculated and checked. If the sum is not two's-complement 
zero, the handler has been destroyed and this portion of the 
OS initia1ization terminates (no error is reported); 


3. 



If the linkage table checksum is OK. the handler is re linked 
and re— initialized according to the procedure of steps 2 
through 6 of section on INIT. AND LINKING DURING POWER-ON; the 
MEMLO parameter is set on so that the handler size will be 
added to MEMLO; 
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4. If an error occurs while re-initia1izing the handler# this 
portion of OS initialization is terminated (no error is 
reported ) i 

5. The forward pointer for the handler linkage table chain in 
this handler's linkage table is checked. If it is null 
(zero), this phase of initia1ization is complete. If it points 
to another handler* steps 2 through 5 are repeated for each 
handler in the chain. 



A1200 SUBROUTINE INTERFACES 


Three subroutines are added to aid the initia 1ization process for 

t oaded handlers. The first searches the handler table for an empty 
lot and makes the entry for the handler. The second follows the 
handler linkage table chain to remove a handler from the chain. The 
third performs initia1ization processing for a loaded handler. 


All three routines are called via USR to the appropriate entry 
vectors (below). All parameters are passed through the machine 

registers. 

The entry addresses for these routines is as follows: 


E489 hex 
E48C hex 
E48F hex 


Handler Entry Routine 

Handler Linkage Removal Routine 

Handler Initia1ization Routine 
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HANDLER ENTRY ROUTINE 


Parameters for this routine are provided in the machine registers. 
|The routine is written for use by the OS handlers. 

The parameters it uses are passed as follows: 


X: Handler name; 

A: High byte of linkage table start address; 

Y: Low byte of linkage table start address. 

This routine searches the handler table from start to the first empty 
slot. If no empty slot is found (the table is full). the carry is set 
on return to the handler to indicate an error. If a duplicate handler 
name is found, a different error is returned (also see below). If 
neither of these error occurs, the handler entry is inserted into the 
table at the first empty slot. 

If the entry was successful made, the Carry bit is cleared on return 
to the handler. 

If the handler table is full, error return is indicated by setting the 
carry bit. This error is distinguished from the dup1icate-entry error 
by also setting the Negative bit. The registers are undefined when 
this return is made. The handler should not proceed with 
^initialization; see section on INIT. AND LINKING DURING POWER-ON. 

If there is a duplicate handler name in the table, the condition is 
indicated to the calling handler by returning with Carry set and 
Negative clear. In this case the A and Y registers are returned to 
the handler unchanged from the call, and the X register is an offset, 
relative to the first byte of the handler table, pointing to the 
second byte of the 3-byte table entry where the matching device name 
was found. The handler has the choice of discontinuing 

initia1ization. replacing the older handler entry, or chaining itself 
in (replacing the old entry but saving it in order to call the older 
handler whenever an I/O call belongs to the older handler). 
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HANDLER LINKAGE REMOVAL SUBROUTINE 


WThis routine undoes the handler linkage performed by the HANDLER 
^RlNTRY routine. Its parameters are also passed to it within the 
machine registers. The parameters required are as follows: 


A; High byte of address of handler linkage table* 

Y: Low byte of address of handler linkage table. 

This subroutine searches the handler linkage table chain for the 
linkage table having the address passed in A and Y. The linkage table 
checksums is computed and checked along the way to verify the 
integrity of the chain. When the proper linkage table is found, the 
handler size is checked to determine whether or not the handler was 
loaded at MEMLO. If the handler size is nonzero, the handler was 
loaded during power up at MEMLO, and it is illegal to remove it. In 
this case, the subroutine returns with the Carry set. Otherwise, the 
linkage table is removed from the chain by copying its forward chain 
pointer contents into the forward chain pointer of its predecessor in 
the chain. 

If the chain search terminates either by finding the end of the chain 
(null pointer) or a bad linkage table, no action is taken and the 
Carry bit is returned set to indicate the error. Carry is cleared to 
indicate that the table was found and removed. The other registers are 
^^jndefined upon return. 

This subroutine is supplied to allow an application to request removal 
of a previously loaded handler when it is no longer needed or when the 
RAM must be reclaimed. It is suggested that the handler CLOSE routine 
check the flag HNDLOD (02E9 hex); it may be set nonzero by the 
application before CLOSE to indicate that the application wishes the 
handler unloaded. The handler is responsible for removing itself when 
unloading is requested: the handler table entry should be deleted, 

and the linkage table must be removed from the chain. The IOCB byte 
ICHID may be used to find the handler table entry, and this subroutine 
is used to remove the link from the chain. CNote: The OS variable 

COLDST is interrogated by this routine to determine when the caller is 
the operating system itself at cold start time. In this case, the 
handler is unlinked even though it is loaded at MEMLO. 1 

Note that, except as described in the paragraph above, the handler 
must NOT remove itself if it has been loaded at MEMLO. This is the 
reason that this subroutine checks the handler size for 
application—1oaded handlers. If the handler receives error status 
from this subroutine, it should NOT remove itself from the system 
(except it is still permissible to remove the handler table entry). 

Handler table removal is done by zeroing the device name byte in the 
handler table. 
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INITIALIZATION SUBROUTINE 


An INITIALIZATION subroutine entry point is included in the OS to 
provide the handler init ia 1 ization function to be easily performed 
when handlers are loaded by a non-OS routine# for example by 
AUTORUN. SYS. 

The INITIALIZATION subroutine performs all the tasks (steps 1-6) 
for initialization described in section on INIT. AND LINKING DURING 
POWER—ON. This routine requires the following parameters to be passed 
to it in the machine registers: 

A: High byte of address of handler linkage table# 

Y: Low byte of address of handler linkage table. 

In addition# the Carry bit must be set by the caller to indicate 
whether the handler size should be added to MEMLO: Carry set on means 

the subroutine allows the adding of the handler size to MEMLO. 

Carry clear means the handler size is zeroed# thus suppressing 
its addition to MEMLO. 

This subroutine returns to its caller with the Carry set if a 
linking error occurred (and the linking is not performed). Carry will 
be clear if linking was successful. 
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APPENDIX D 


RELOCATING LOADER 


L yA 12.00 . , . 

pr ^0 Operating System ROM includes a 

used to load certain types of object code. 


subroutine which can be 


results. This loader is 


of spac 

e a 

s/a i 

lab le 

in 

the OS ROMi 

only a 

hecking 

can 

be 

done 

. 

Therefore# a 

strict set 

shed for 

th 

e f 

ormat 

of 

object code 

which can 

cilities 

of 

th 

is bu 

ilt 

—in loader. 

If the 

1 lowed # 

you 

wi 

11 ob 

ta i 

n unpredictab 

le 

ot acces 

sib 

1 e 

to us 

er 

programs. It 

; is only 

per iphe 

ra 1 

d e 

signe 

r s 

with data app 

ropriate 

the hand 

ler 

ob 

j ec t 

cod 

e. 



FORMAT OF THE LOADER PARAMETER BLOCK 


Before executing the relocating loader subroutine, the OS provides 
the loader with certain information. This is a table of data located 
at hexadecimal 02CF within the OS RAM area. A total of 5 bytes of 
data must be provided. They are organized as shown here: 


-- + 

low byte S GETBYTE ADDRESS i $02CF 

+ + 

^iigh byte S ^ 

low byte ! LOAD ADDRESS 5 *02D1 

+ + 

highbyte! ' 

- -- 

one byte i ZLOAD ADDRESS i *02D3 

+ -- 


The interpretation of the bytes in this table is as follows: 

The GETBYTE address is a two byte address of the entry point for the 
Get Byte routine. This may refer to an existing GETBYTE 
routine for a peripheral already supported with coresident code. 
SUBROUTINE" below. 

The LOAD ADDRESS parameter specifies the base address from which the 
calculation of actual object code placement and cross reference will 
be made. For example, if the relocatable object code was all 
assembled to be relocated with respect to its own location OOOO and 
the LOAD ADDRESS specifies OO (low byte), 90 (high byte), then the 
code will be loaded beginning at $9000. All relative relocatable 
address references will then be changed to reference the new code 
location at *9000. 






The ZLOAD ADDRESS is a one byte zero page address which is used as the 
base address for the relocation of any zero page references used in 
the relocatable code. Any references to page zero variables are 
adjusted during relocation by adding this ZLOAD ADDRESS as an offset 
;o the relocatable address. This forms the actual load address for 
the variable and its references. 


LOADER—TO-USER PARAMETER BLOCK 

Before the OS called the loader routine# it had to provide a block of 
parameters to give the loader various information. The loader# in 
turn# provides a return set of parameters. 

These parameters will allow the OS to determine where the next 
relocatable subroutine may be loaded# if desired# to allow a sequenced 
loading of many such routines. It also provides you with the absolute 
RUN address once the relocation has taken place to allow a jump into 
the now resident routine. 

Here is a diagram showing the way the table appears in memory. It 


begins at 

he xadecima1 

address $02C9. 







lour byte 

high byte 

« 

a 

+ 

a 

a 

RUN 

ADDRESS S 

+ 

a 

a 

*02C9 

low byte 

% igh byte 

a 

a 

+ 

a 

a 

HIGH 

USED ADDRESS 

+ 

a 

a 

♦02CB 

one byte 

SZpage Hi 
+- 

Used Address 5 

- + 

*02CD 


RUN ADDRESS is the execution entry point. It has been calculated 
by the Loader as the absolute address which was specified from the 
data in the END record. If the RUN ADDRESS is zero# then you did 
not specify a run address in the END record. (Record structure 
is covered in the next section). 

• * /Lf ttirru"-' * ' £ r*' &GZC*? 

<ri- -r t? j r ~ a- re. c tec and 

HIGH USED is the address of the next available memory location 
above that which has just been used by the loader. If there are 
multiple relocatable routines to be loaded# the information in the 
low and high bytes of this parameter may be moved directly into the 
User—to—1oader parameter block to direct where the NEXT routine 
is to be loaded. The equivalent locations within that parameter 
block are *02D1 (low byte) and $02D2 (high byte) of the LOAD 
ADDRESS. 
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Zpage Hi Used is the address of the next available zero page 
memory location above that which has just been used by the loader. 
If there are multiple relocatable routines to be loaded/ the 
ffata in this parameter may be moved directly to location $02D3. 
*he ZLOAD ADDRESS. This allows a chain of relocatable files to 
dynamically configure themselves in the memory using the loader's 
output as the input of the next loader call. 

RECORD STRUCTURES 


The relocatable object file consists of a sequence of one or more 
segments. An object segment consists of a single TEXT record 
followed by one or more INFORMATION records. The format of the 
TEXT and INFORMATION records is discussed in the sections which 
f ol low. 

The Loader processes the data obtained by the GETBYTE routine 
as object segments. The TEXT record is a sequence of machine 
instructions and data. The INFORMATION record(s) associated with 
each TEXT record specify exactly which of the bytes within the 
TEXT record will have to be modified in order to relocate the 
code to its intended location. 

The relocation process begins with the Loader taking a TEXT record 
and loading it into the memory area at the absolute address calculated 
from the load address provided. (There may be many TEXT 
records in any single relocatable object file). Then the loader 
'eads the next record to see if it is an INFORMATION record. An 
INFORMATION record will show the loader which bytes in the loaded 
code will have to be modified. If there is no INFORMATION record 
associated with this TEXT record/ no modification takes place. 
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If the TEXT record does include address references which must be 
relocated, the INFORMATION records which cause the modification 
must immediately follow that TEXT record in the record grouping. 
You may therefore consider one TEXT record and a number of 
INFORMATION records as though it is one complete segment. 


The entire relocatable file processe 
of any number of TEXT/INFO record gr 
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{ECORD FORMAT DEFINITION 
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The loader expects the input records to be formatted in a specific 
manner. The individual formats for the TEXT* INFORMATION* and END 
records are given below. The common element between them is the 
first byte of the record* which specifies what type of record is 
0 o be processed. The first byte of the record is known as the 
Type ID. As a summary* the various Type ID's associated with each 
record type are as follows: 


TYPE ID RECORD TYPE 


OO 

01 

02 

03 


04 


05 

06 



07 

08 


TEXT - Contains Non-zero-page Relocatable Text 

TEXT — Contains Zero-page Relocatable Text 

INFO - Points to non-zero page low byte references 
to non-zero page data in a text record 

INFO - Points to zero page low byte references to 
non—zero page data in a text record 

INFO — Points to non-zero page single byte reference 
to zero page address within a text record 

INFO - Points to zero page one byte reference to 
zero page data in a text record 

INFO — Points to non—zero page word references to 
non-zero page data in a text record 

INFO - Points to zero page word references to 
non-zero page data in a text record 

INFO - Points to non-zero page high byte references 
to non-zero page data in a text record 


09 INFO — Points to zero page high byte reference to 

non—zero page data in a text record 

OA TEXT - Contains absolute* nonre1 ocatb1e object code 

OB END - Is an END record 


All of these various record types and pointers are illustrated by 
example in the sections on TEXT RECORDS* INFORMATION RECORDS and 
END RECORD below. 



TEXT RECORDS 




TEXT RECORD is a group of bytes containing machine language 
nstructions and data. It will be loaded intact to a specific 
area of memory* then the Loader will modify some or none of the 
bytes AFTER placement into RAM according to instructions provided 
in the INFORMATION records which immediately follow this TEXT 
RECORD. 


There are three types of TEXT records which may be specified: 


A. 


B. 


(• 


A record containing non-iero page relocatable text. This is 
data which is loaded into an area in an area other than zero 
page ($0100—$FFFF) somewhere and whose address references 
must be modified to reflect the actual area into which it. 
and its corresponding zero page segment* have been loaded. 

A record containing zero page relocatable text. This is 
data which is loaded into an area within zero page ($0000- 
$OOFF) somewhere and whose address references must be modi¬ 
fied to reflect the actual area into which it. and its 
corresponding non—zero page segment* have been loaded. 

A record containing Absolute text. This type of data 
does not need any adjustment to its address references. 

A TEXT record of this type will not have any INFORMATION 
records following it. (INFO records specify the 
relocation data and this type of text does not need any.) 


TEXT RECORD FORMAT 


Here is a 


representation of the content of the typical TEXT record. 


+ - 

5 TYPE 

J ID 

t 

« 

! Length 

« 

< 

• 

« 

8 Relative Address 8 Object 
! or 8 

8 Absolute Address 8 

+ - 

< 

low byte high byte 

1 byte 

1 byte 

2 bytes 0-253 by 

The TYPE 
■f o 1 lowing 

ID field 
values. 

for a TEXT record will contain on 
For a complete description of th 


record type* see TEXT RECORDS above. 
VALUE TYPE OF TEXT RECORD 
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OO Non-zero page relocatable text 

Ol Zero page relocatable text 

OA Absolute text 

^|fhe LENGTH field for a TEXT record will have a value from 2 to 255. 

It is computed as the total count of bytes contained in the record 
counting from the first byte following the Length byte to the end 
of the record. (A complete text record therefore can consist of 
a minimum of 4 bytes, to a maximum of 257 bytes). 

The ADDRESS field specifies either an Absolute or a Relative Address. 

If it is an Absolute Address record type, the object text contained 
in this record is to be loaded to memory at the starting address 
specified in this absolute address field. Each byte in the text 
is then to be loaded into the next higher address until the 
entire record has been loaded. 

If it is a Relative Address record type, the object text contained 
in this record is to be loaded to memory at the specified address 
RELATIVE to the starting address of the relocatable code. The 
address field is specified as relative to starting address OOOO 
which is assumed to the the first location within a code segment. 

The actual address to which this code will be loaded is calculated 
by the Loader by adding the LOAD ADDRESS offset (See USER—LOADER 
PARAMETER BLOCK) to the relative address contained in the record 
itself. The relative address is the 16-bit offset from the 
beginning of the actual program so the placement in RAM will 
therefore be relative to the starting location which you 
(p ecified in the parameter block. 

INFORMATION RECORDS 


INFORMATION records are the modifiers for the TEXT records. There 
may be no information records or many of them. 

There are two basic types of information records: those which 

reference single byte data or low byte of an address, and those which 
reference the high byte of an address reference. 

LOW BYTE. ONE BYTE, AND WORD REFERENCE INFORMATION RECORDS 

The format of an information record which can modify low 
byte address references, one byte (page zero) addresses 
or word references (those which modify a 16—bit address 
and point to the low byte of that quantity) is shown here: 


5 TYPE i LENGTH 5 Offset 1 ! Offset 2 ! Offset N 5 

1 ID I « i S * 
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The TYPE ID field will specify the type of reference for which the 
offset specifies the location. The TYPE ID's for which this format 
is valid are the following: 



TYPE ID REFERENCE TYPE 

02 Non-zero page low byte reference to a non—zero 

page address. This means that you may have 
referenced something similar to the following: 

LDA #L#NZREF jget the low byte of the 

* 16-bit integer assigned 

# to address NZREF 

This will be an address relative to the beginning 
of the relocatable file. If the offset points 
to the immediate value* it is this value which 
will be modified when the LOAD ADDRESS low byte 
is added to it to obtain the actual current load 
address. The TYPE ID indicates that this instruction 
is loaded into a non-zero page area. 

Example: Code loaded into location $1000# 

LOAD ADDR is $0D01* 

NZREF is located at relative address 0050 
If code is LDA #L# NZREF# then loader sees: 
$1000 A9 (LDA) 

*1001 50 <-offset points here 

Load address low byte is $01 

Value found at pointer is $50 

Loader adds them# replaces value at pointer with $51 

03 Zero page low byte reference to a non—zero 

page address. This is exactly as described for 
Type ID 02 above except that the code which is 
to be relocated has been loaded into a page 
zero area instead. The rest of the explanation 
remains exactly the same. 

04 Non—zero page one byte references to a zero page 

address. This means that a code segment such as: 

LDA ZPAGE1 # where ZPAGE1 is an address 
within page zero# 

produces a relocatable code. This code# when stored 
in a non—zero page area# may have to be relocated 
if ZPAGE1 is a relative address. In this case# the 
example might show the following: 
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05 


Example: Assume that the code specified above 

is loaded at $1000# and ZPAGE1 is 
zero page address $0045. Also assume 
that the ZLOAD ADDRESS you specified 
earlier (see USER-LOADER PARAMETER BLOCK) 
contains $10. 

$1000 A5 (LDA ... zpage ) 

$1001 45 <- Offset points here 

The Loader will take the byte at the pointer/ add 
the ZLOAD Address offset/ and replace the value at 
the pointer with the newly calculated relocated value. 
In this example, $45 is fetched, adds the offset $10, 
so the relocated address value is $55 stored into 
location $1001. 

Zero page one byte reference to a zero page 
address. This is exactly like the relocation 
example shown for Type ID 04 above. The only 
difference is that the code which has been loaded 
resides in a page zero area and is modified there. 

In the example, the load address, then, could have 
been $OOAl, instead of $1000. All else remains 
the same. 


06 Non—zero page word reference to a non-zero 

page address. This means the offset points to 
the low byte of an object code address reference 
of code which has been loaded into an area not 
in page zero. 


Example: Code loaded to location $1000, 

consisting of LDA $1234, loaded as: 


$1000 AD 

$1001 34 < offset points here 

$1002 12 


(note that the address $1234 is an address relative 
to the start of the object code file itself, which 
starts, relative to itself, at location OOOO) 

07 Zero page word reference to a non—zero page 

address. This means the offset points to the 
low byte of an object code address reference 
of code which has been loaded into an area not 
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in page zero. 


Example: 

Code loaded to location 
consisting of LDA $1234, 

$0023, 
loaded as: 

$0023 

AD 


$0024 

34 <-offset points 

here 

$0025 

12 



Non; that we've gone over the TYPE ID's for 02—07# the other fields in 
this INFORMATION record can be explained. Recall from above they are: 
TYPE ID# LENGTH# and OFFSET. 

The LENGTH field in this record type specifies the total byte count of 
the number of OFFSETS which are contained in this record. In other 
words# it specifies how many of the bytes within the previously loaded 
TEXT record are to be modified by the Loader using this specific TYPE 
ID. There will be that number of pointers as a part of this record. 

The length field may specify a value from O to 255. 

The OFFSET field specifies a value from O to 255# one byte for each 
offset. This forms a pointer which# when added to the starting 
address for the text record just loaded# gives the address of 
^he byte which is to be modified per the relocating instructions 
(illustrated above. As noted# there may be as many as 255 offsets 
total contained in any INFORMATION record. 


SUMMARY OF LOADER PROCESSING FOR WORD# LOW BYTE AND 
SINGLE BYTE INFORMATION RECORDS 

1. The preceeding TEXT record has been read and its object 
code has been placed into RAM at the appropriate 
displacement relative to the preceeding relocatable 
text record. 

2. Each offset is used to obtain a data value (either 
one or two bytes# depending on record type) from the 
preceeding object text record. 

3. The base address (user specified Load Address) is 
added to the value obtained. 

4. The resulting value (one or two bytes# depending on 
record type) replaces the data value at the specified 
offset location in the RAM. 


HIGH BYTE REFERENCES IN INFORMATION RECORDS 


26 



The record formats for these cases, TYPE ID's 08 and 09, are different 
from those just discussed. This is due to a different type of data 
required to calculate the correct address reference. 

Ln the last tu>o cases, (TYPE ID 06 and 07), the pointer specified the 
low byte of a two byte address. In order to calculate the correct two 
byte address after adding the offset, and to replace both bytes with 
the correct relocated address, this single offset pointer is 
sufficient. The loader will know, in other words, that the high byte 
immediately follows the low byte, in the next sequential offset 
1 ocat i on. 

However, in the TYPE ID references which follow, the Loader needs more 
information in order to be able to calculate the correct address. 

Therefore the format of the INFORMATION record for TYPE ID's 08 and 09 
appears as follows: 


- -- /—+ 

i TYPE 2 LENGTH 2 OFFSET 1 2 Low 2 OFFSET 2 2 Low 2 MORE DATA 2 

j ID 2 2 2 Byte 1 2 2 Byte 2 2 Pairs 2 

+ -- /--+ 

If you are referencing the high byte of a relocatable address, the 
record which contains this reference must also contain a reference 
to the low byte of that address. This would occur as follows: 


Examp 1e: 

The 
of a 

correct way to reference a high byte 
relocatable address ... 



LDA 

#L, RADDR 

; get low byte. This must be 
{located within the SAME TEXT 
{record as the reference to the 
,-high byte! 


STA 

TEMP 

{do something with it 



LDA 

#H, RADDR 

{get the high byte of the 
{relocatable address 



STA 

TEMP2 

{do something with it 


If RADDR 
stored at 
foilows: 

is relative location *1234, then the code, 
some location (example — $1000), would look 

wh en 

as 

$1000 

A9 

(LDA . . . 

immediate mode) 



$1001 

34 

<- TYPE ID 

08 offset 1 

p o in 

$1002 

8D 

22 22 (assumes 

temp storage 

spot 



address 

$2222 for example 
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$1005 A9 (LDA ... immediate mode) 

$1006 12 <- TYPE ID 08 offset 2 points here 

bhat the relative code assembler will do is to organize the code 
so that both references to the high and low bytes occur within the 
same 256 byte block of TEXT record. Then a TYPE ID 08 INFORMATION 
record can be used to reference and modify it as shown above. 

The Loader will take the byte pointed to by Offset 1 and treat 
it as the low byte of a relative address. It will also take the 
byte pointed to by Offset 2 and treat it as the high byte of a 
relative address. To this combination relative address, it adds 
the LOAD ADDRESS (see USER-LOADER PARAMETER BLOCK). 

The high byte of the result replaces the high byte of the relative 
address. If there are any other byte pairs specified as part of this 
TYPE ID 08 INFORMATION record, they too are processed in the same way. 

The low byte of the result is DISCARDED. NOTE, if there is a low 
byte which must be relocated as well as its high byte, it must be 
done by a TYPE ID 02 or 03 INFORMATION record. This record MUST 
FOLLOW that which processed the high byte 08 or 07 type record. 


(M 


To summarize, then, the record types 08 and 09 are provided for 
the control of references to the high bytes of relocatable addresses. 
The only difference between a type 08 and 09 INFORMATION record 
s that the TYPE ID 08 is used to process TEXT records loaded 
to non—zero page areas of memory. A TYPE ID 09 record accom¬ 
panies a TEXT record loaded into zero page. 


END RECORD 


The END record is the last record processed by the Loader. It 
has a TYPE ID of hexadecimal OB. 

The END record always consists of four bytes. The first is, as 
usual, the TYPE ID. The second byte is called the self-start 
flag. The value in the self-start flag has the following meaning: 

INTERPRETATION 

Program execution after relocation is not required. 
The two bytes which follow the self start flag in 
the END record are ignored, however must still have 
been provided to the Loader. The RUN ADDRESS 
(See LOADER-USER PARAMETER BLOCK) is left as OOOO. 

This tells the Loader that the execution entry point 
address contained in the END record is an absolute 
address. 


VALUE 

OO 

Ol 
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02 


This tells the Loader that the execution entry point 
address contained in the END record is a relative 
address. To obtain the absolute address, the user 
provided LOAD ADDRESS is added to the relative address 
contained in the END record. 

The calculated absolute start address (or OOOO if none is required) 
is placed into the RUN ADDRESS location within the LOADER-USER 
parameter block. After the processing of the END record, the 
Loader returns to the calling routine with an RTS. 



V. WCUACi 


To: Robert A. Peck Date: January 10, 1983 

From: Harry B. Stewart 

Subject: Review of A1200 Operating System Manual Supplement 


I have reviewed the Atari A1200 Operating System Manual 
Supplement. My comments follow. 

Page 1, second paragraph: It is not clear what the word "watch" 
means in the sentence containing "... you must not only watch 
the keyboard for incoming ATASCII codes . . .". You might also 
include an analogy to the BREAK key and data base variable 
BRKKEY. 

Page 2: Change three occurences of "The default code is 
reassignable, however ..." to "The default function is 
reassignable." . 

Page 3: Change one occurence of "The default code is 
reassignable, however ..." to "The default function is 
reassignable.". 

Page 3, second paragraph: Include the information that follows, 
in your own words. 

CTRL-F1 tbggles between keyboard enabled and keyboard 
disabled. When the O.S. disables the keyboard, LED 1 will be 
lit. 

List the exceptions on this page instead of where listed 
currently on page 10. 

O.S. variable KEYDIS at location 026D may also be accessed 
by the user to control or monitor the keyboard enable/ 
disable function; a value of 0 enables the keyboard, and a 
value of $FF disables the keyboard. 


Page 4, first paragraph: Delete "(See the ATARI ... variable.)" 
and include the information that follows, in your own words. 

The O.S. disables the DMA using the following algorithm: 


IF KBCODE = CTRL-F2 THEN 
BEGIN 

IF SDMCTL <> 0 THEN 

BEGIN { DMA not already disabled } 

DMASAV :=.SDMCTL; { save DMA control value } 
SDMCTL := 0 { disable DMA } 

END 


.END 



ELSE { KBCODE <> CTRL-F 2 } 

IF DMASAV <> 0 THEN SDMCTL : = DMASAV { enable DMA } 


Page 4, second paragraph: Delete the word "combination" from 
"This function combination . ..". 

Page 5, third paragraph: Change all occurrences of n C8" to "CC"• 
Also include the information that follows, in your own words. 

Two variables are used to control the character set 
selection: CHBAS [02F4] and CHSALT [026B]. The Screen 
Editor (E:) and the Display Handlere (S:) initialize 
variables CHBAS and CHSALT at every OPEN command. CHBAS is 
initialized to a value of $E0 and CHSALT is initialized to 
a value of $CC. 

CTRL-F4 utilizes the algorithm shown below for character 
set selection: 

IF KBCODE = CTRL-F4 THEN 
BEGIN 

TEMP := CHBAS; { swap CHBAS and CHSALT } 

CHBAS := CHSALT; 

CHSALT := TEMP; 

IF CHBAS := $CC THEN LIGHT LED 2 
END 

Page 6: The term "bottom-most" is confusing. Perhaps the 
diagram itself could indicate low address and high address. 

Page 7, first paragraph: Change "... 80 to 92 ..." to "... 80 to 
91 

Page 7, first table: Change "Gonzo function" to "ATASCII code". 

Page 7, second paragraph: Delete "This function will be ... will 
produce.". 

Page 8, last two paragraphs: Combine them and include the vector 
name , "KEYDEF". 

Page 9, first paragraph: Change "these keys only" to "only the 
function keys". 

Page 9, second paragraph: Indicate that the same codes as 
described on page 7 are used in this table, except that codes 8A 
to 8D can cause an infinite loop situation. 

Page 10: Indentation is not consistent. 

Page 10: The exceptions to the keyboard disable function should 
be included on page 3, where CTRL-Fl is described, not here. 
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Page 11, second paragraph: State explicitly that the key repeat 
rate equals the VBLANK rate (60 or 50 per second) divided by the 
KEYREP value. 


Page 11, last sentence: Change "All keys ..." to "All alphabetic 
keys (A-Z)...". 


Page 12, section 3.7: Add a note that cartridge 
removal with power on may also cause the system 
(because the 6502 processor bus is subjected to 
pressing the RESET key will cause the system to 
properly. 


insertion or 
to "crash" 
noise) and that 
recover 


Page 13, last two tables: Indent them the same. 

Page 14, section 3.11: Add the following information, in your 
own words. 


The following behaviors are associated with the selection of 
fine scrolling. 

There are only two allowed values for FINE: 0 and $FF; 
other values may produce undesireable results. 

On OPEN, if FINE [026E] is $FF then a fine scrolling 
display list is created, which is one byte larger than 
a coarse scrolling display list. Also, the address of 
a display list interrupt routine is placed into the 
display list vector VDSLST [0200]; this overrides any 
other vector that might be there. 

• When fine scrolling is enabled, the Screen Editor's 
display list interrupt service routine modifies the 
content of color register C0LPF1 [D017] for the very 
last visible scan line of the screen. 

On CLOSE, if FINE is $ FF then the address of an RTI is 
placed into, the display list vector VDSLST [0200]. For 
O.S. versions 11 and beyond: FINE is set to zero, and the 
screen is reopened with a coarse scrolling display list. 


The recommended manner for enabling and disabling fine 
scrolling is shown below. 

1. Set FINE to $FF. 

2. OPEN E: using any IOCB #. 

3. Use E: as usual; fine scrolling is enabled. 

4. CLOSE E:. 

x’Ti —I ■£ — the — FOCB —i-s—fto-w-open—t-b-erv-you-are don e , other wi se 
__ c QXi t i n 11 q. —~i-tns IT^>FT"“~ste’p. — 

6. Set FINE to 0. 

7. OPEN E:. 

Page 15, A1200 MEMORY MAP: "Active, low chip selects ... 


page. 



seems a bit technical; how about just indicating that the 
special purpose chips respond to the addresses shown. 

Page 16: Move "A1200 MEMORY MAP (cont'd)" to top of page. 

Page 16, first two paragraphs: Could the discussion of RD5 and 
RD4 be made a parenthetical note to a sentence relating to the 
cartridge being either inserted or removed? 


SECOND SECTION (Page numbers absent) 


PERIPHERAL HANDLER ADDITIONS not reviewed by me; check with 
Scott Scheiman for comments. 

A1200 OS ROM IDENTIFICATION AND CHECKSUM DATA, second page: 
Change the Option byte description at C005 to indicate that the 
byte is reserved and contains $00 for the A1200. 

A1200 OS ROM IDENTIFICATION AND CHECKSUM DATA, third page: 

Change the Option byte description at FFF1 to indicate that the 
byte is used as a hardware product identifier and contains $01 
for the A1200. Every future Atari Home Computer Product which 
is A1200 compatible will have a different unique identifying 
number in this byte. 

APPENDIX B, first page: Change "... formed out of 8 pixels 
'(smallest ..." to "formed from an 8 wide by 8 high pixel 
matrix.". 

APPENDIX B, first page: Change "Each pixel is 1/2 ... wide." to 
"Each pixel is one bit wide in memory and is 1/2 of a color 
clock wide on the screen.". 

APPENDIX B, first page: Change "... formed out of only 4 pixels, 
..." to "formed from a 4 wide by 8 high pixel matrix,...". 

APPENDIX B, first page: Change "with each pixel 1 color clock 
wide.” to "with each pixel 2 bits wide in memory and 1 color 
clock wide on the screen.". 

APPENDIX B, first page: Change "... within 4 bits ..." to 
"... within 4 pixels ...". 

APPENDIX B, first page: Change "... either the color ... 
luminance of playfield 1 ..." to indicate that a 0 pixel value 

will use the hue/lum from PF2 and that a 1 pixel value will use 
the hue from PF2 and the lum from PF1. The term "background 
color" normally refers to the value in register BAK. 

APPENDIX B, first page: Change "... 8 by 8 matrix, ..." to "... 

8 by 8 matrix.". 
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APPENDIX B, second page: Change "... doubles the length of ... 
to "... doubles the height of ...". 


APPENDIX B, second page: Change "... form a W in the character 
set ..." to "... form a W in the default charater set ...". 


APPENDIX B, third page: Change "As may be imagined, difficult 
..." to "As may be imagined, it is difficult ...". 

APPENDIX C not reviewed by me; check with Scott Scheiman for 
comments. 

APPENDIX D not reviewed by me; check with Scott Scheiman for 
comments. 


Somewhere in the document, include the information shown below. 


Port B changes -- Since PORTB is a read/write port, all changes 
should be made as shown below: 

Clear a bit (b) 

LDA PORTB 
AND # $FF-b 
STA PORTB 



Set a bit (b) 

LDA PORTB 
ORA 5b 
STA PORTB 


Rev determination — In order for a program to determine which 
Atari Home Computer product and Operating System revision it is 
operating with, the following tests are recommended. 


If location $FCD8 = $A2 then product is an 
if location $FFF8 = $DD and $FFF9 = $57 

if location $FFF8 = $D6 and $FFF9 = $57 

if location $FFF8 = $F3 and $FFF9 = $E6 

if location $FFF8 = $22 and $FFF9 = $58 

else some other future A400/A800 operat 
else product is an A1200 or future product 
if location $FFF1 = $01 then A1200 
location $FFF7 = 


else location $FFF1 
location $FFF7 = 


O.S. internal 
the A1200 

= product identifie 
O.S. internal revis 
this product 


A400/A800 
then NTSC 
then PAL 
then NTSC 
then PAL 
ing system 


revision number 


r number 
ion number 


Rev A 
Rev A 
Rev B 
Rev B * 


for 


for 
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* NOTE: The Rev B PAL O.S. has not been released as yet, 
values shown may change. 



the 
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Shown below is a list of the pages within C016555 Rev. A which 
have incorrect or incomplete information as regards the 1200 


product. 



Page 44: Truncated record in GET RECORD. 

Page 50: CAPS key description. 

Page 52: Keycode conversion. 

Page 53: Keycode table. 

Page 54: New screen modes. 

Page 55: Fine scrolling. 

Page 56: CHBAS and international character set. 

Page 58: Formats for new modes. 

Page 59: Formats for new modes. 

Page 66: Editing from keyboard (function keys). 

Page 67: Fine/coarse scrolling selection at OPEN. 

Page 67: Fine scrolling deselection at CLOSE. 

Page 99: PUT SECTOR. 

Page 103: [SYSTEM.RESET) not NMI. 

Page 104?: CLD inclusion. 

Page 104: Color register update. 

Page 106: Controller reading. 

Page 113: WSYNC discussion doesn't apply. 

Page 115: Correct flowchart for RESET. 

Page 116: [SYSTEM.RESET] not NMI. 

Pages 116-120: New init sequence. 

Page 145: The 'NOTE: There is a bug ... ' message no 

longer applies. 

Pages 145-147: New SIO bus hardware specs. 

Page 157: Hardware cartridge sense. 

Pages 172-173: International set + new. modes. 

Pages 188-189: New screen modes. 

Page 191: 815 command codes do not apply. 

Page 192: There are new vectors in the vector area. 

Pages 200-270: New database stuff (See attached pages). 
Page 212: New screen modes. 

Page 222: New screen modes. 

Page 240: New memory sizing algorithm. 

Page 255: VDSLST used by Screen Editor for fine scrolling. 

Page 257: Internatinal character set. 


cc : 



Bob Braun 
Paul Laughton 
Scott Scheiman 
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<P2&8 Qii cHSftLT — ikfrl cUt. 


DATA BASE CHANGES FROM REV. B TO 3 200 


1 


LOCATION 

REV. B 

USE 


1200 USE 


0000 

reserved 


LNFLG — 

for inhouse debugger. 

0001 

*t 



NGFLAG — 

for power-up self test. 

001C 

PTIMOT 

-- 

to 0314 

ABUFPT — 

reserved. 

001D 

PBPNT 

— 

to 02DE 

n 


^ 01 E 

PBUFSZ 

— 

to 02DF 

« 


001F 

PTEMP 

— 

eliminated 

" i 


0036 

CRETRY 

— 

to 029C 

LTEMI* — 

loader temp. 

0037 

DRETRY 

— 

to 02BD 

ft 


0 0 4 A 

CKEY 

— 

to 03E9 

ZCHAIN — 

handler loader temp. 

004B 

CASSBT 

— 

to 0 3EA 

tt 


0060 

NEWROW 

-- 

to 0 2F5 

FKDEF 

func key def ptr. 

0061 

NEWCOL 

— 

to 02F6 

M 


0062 

*t 



PALNTS — 

PAL/NTSC flag. 

0079 

ROWINC 

— 

to 02F8 

KEYDEF - 

key def ptr. 

007A 

COLINC 

— 

to 02F9 

ft 


0233 . 

reserved 


LCOUNT — 

loader temp. 

0238-0239 

m 



RELADR — 

loader. 

0245 

ft 



RECLEN — 

loader. 

0247 1 

LINBUF 

— 

eliminated 



\__ fc l3248-026$A 

■ 




reserved. 

0 26C 

M 


VSFLAG 

-- 

fine scroll temp. 

W 026D 



KEYDIS 

— 

keyboard disable. 

• 0 26E 

■ 


FINE 

— 

fine scroll flag. 

0288 

CSTAT — 

eliminated 

HIBYTE 

— 

loader. 

0 28E ‘ 

reserved 


NEWADR 

— 

loader. 

0 29C 

TMPX1 — 

eliminated 

CRETRY 

— 

from 0036. 

02BD 

HOLD5 — 

eliminated 

DRETRY 

— 

from 0037. 

02C9-02CA 

reserved 


RUNADR 

— 

loader. 

02CB-02CC 

m 


HIUS ED 


loader. 

02CD-02CE 

m 


ZHIUSE 

— 

loader. 

02CF-02D0 

ft 


GBYTEA 

— 

loader. 

02D1-02D2 



LOADAD 

— 

loader. 

02D3-02D4 

at 


ZLOADA 

— 

loader. 

02D5-02D6 

m 


DSCTLN 

— 

disk sector size. 

02D7-02D8 

at 


ACMISR 

— 

reserved. 

02D9 

m 


KRPDEL 

— 

auto key delay. 

02DA 

ft 

. 

KEYREP 

— 

auto key rate. 

0 2DB 

ft 


NOCLIK 

— 

key click disable. 

0 2DC 

it 


HELPFG 

— 

BELP key flag. 

02DD 

ft 


DMASAV 

— 

DMA state save. 

02DE 

« 


PBPNT 

— 

from 0 03 D. 

02DF 

m 


PBUFSZ 

— 

from 00IE. 

0 2E9 

it 


HNDLOD 

— 

handler loader flag. 

02F5 

n 


NEWROW 

— 

f r om 0 0 6 0. 

02F6-02F7 

m 


NEWCOL 

— 

f rom 0 061. 

^ _ 02F8 

ft 


ROWINC 

— 

f rom 0 079. 

™ 02F9 

ft 


COLINC 

- -* 

from 007A. 

030E 

ADDCOR — 

eliminated 

' JMPERS 

— 

option jumpers. 




0314 

• 0 3 3D 
033E 
0 33F 
03E8 
0 3E9 
03EA 
03EB 

03ED-03F8 
03F9 
0 3FA 

6 3FB-0 3FC 






TEMP2 — to 0313 
reserved 


PTIMOT 

PUPBTl 

PUPBT2 

PUPBT3 

SUPERF 

CKEY 

CASSBT 

CARTCK 

ACMVAR 

MINTLK 

GINTLR 

CHLINK 


f r om 

001C. 

powe 

M 

r-up/RESET 

M 

Sere 

en Editor. 

from 

0 0 4 A . 

f r om 

004B. 

cart 

checksum. 

r ese 

n 

r ved. 

cart 

interlock 

handler chain. 




GET CHARACTER DATA FORMATS 


Modes 12,13 - 


Mode 14 -- D 


Mode 15 — D 


PUT CHARACTER 


Modes 12,13 - 


Mode 14 — D 


Mode 15 — D 


7 0 

M = color |M| D I 

modifier 

D = truncated ATASCII 


color | zero |D| 


color I zero I D | 


DATA FORMATS 


7 ' 0 

+ 

M = color |M| D | 

modifier . 

D = truncated ATASCII 


+-+-+-+-+-+-+-+-+ 
color I ? |D| 


color I ? | D | 



CHARACTER DEFINITION FORMAT FOR MODES 12 & 13 



7 0 

I I I I I relative byte 0 

\_ I I I I 

I I I I I relative byte 7 

Each 2-bit color specification in the character definition maps 
to the color registers as shown below: 

0 = BAR 

1 = PF0 

2 = PF1 

3 = PF2 if bit-7 of color modifier = 0, or 

PF3 if bit-7 of color modifier = 1. 


f 




Appendix H (new modes) 



Mode 

f 

Horiz. 
posit. 

Vert, 
w/o sp 

Vert, 
w sp 

Colors 

1 2 

40 

24 

20 

5 

13 

* 

40 

12 

10 

5 

14 

160 

192 

160 

2 

15 

160 

192 

160 

4 


Da ta 

Color 

memory 


value 

r eg. 

r egd. 
(split) 

(full) 

00-7F 

* 

1154 

1152 

00-7F 

* 

664 

660 

0 

BAK 

4270 

4296 

1 

PF0 



0 

BAK 

8112 

81 38 

1 

PF0 



2 

PF1 



3 

PF2 




* See CHARACTER DEFINITION FORMAT FOR MODES 12 & 13 



